Design a Python exception hierarchy that tells your retry logic which failures are worth retrying

Design an error-handling strategy for one specific Python module, including a custom exception hierarchy. The point is to make retryable failures and fatal failures behave differently everywhere this module is called, not to catch everything the same way.

MODULE AND WHAT IT DOES
A module that uploads generated PDF reports to S3 and records the resulting object key in the database.

EXTERNAL DEPENDENCIES IT CALLS
boto3 for S3 uploads, a Postgres connection via SQLAlchemy for recording the object key.

HOW IT'S CURRENTLY CALLED
Called from a Celery task; right now a failure just logs a traceback and the task is marked failed with no retry.

FAILURE MODES ALREADY SEEN
S3 throttling (SlowDown errors) under burst load; occasional Postgres connection drops; occasionally being asked to upload a report for a job_id that was already deleted.

RULES
Design a small exception hierarchy rooted in one base exception for this module, with subclasses that separate failures along the dimension that actually matters to a caller: is this worth retrying automatically (a transient network timeout, a rate limit, a lock-contention error) or not (a malformed input, a permission denial, a resource that genuinely doesn't exist)? Every subclass needs a one-line docstring stating specifically when it's raised and what a caller should do about it — "raised when X happens, caller should retry with backoff" versus "raised when Y happens, caller should not retry, this needs a code or data fix." For each external dependency listed, map its actual failure modes (a specific exception type it raises, or an HTTP status code it returns) onto your new hierarchy explicitly — do not let a third-party exception type leak up through this module uncaught, since that forces every caller to know about and handle a library-specific exception instead of this module's own contract. Attach enough context to each raised exception (the input that caused it, an identifier, not just a message string) that a caller or a log line can act on it without re-deriving what happened from scratch.

WHAT NOT TO DO
Do not create an exception subclass for every conceivable failure if two failures genuinely warrant the same caller behavior — a hierarchy with fifteen leaf types that all just mean "don't retry" is not more useful than three, it's just more surface area to keep in sync. Do not catch a broad `Exception` anywhere in this module's own code without immediately re-raising as one of the new custom types with context added — a caught-and-silently-logged exception here means the caller never finds out the operation didn't actually succeed.

OUTPUT FORMAT
1. The exception hierarchy as Python classes, each with its docstring.
2. A table mapping each known external failure mode to the custom exception it should become.
3. One code example showing the module raising the right custom exception with context attached.
4. One code example showing a caller using the hierarchy to decide retry vs. give up.