Long-Polling Job Status API

Add visibility into how many long-polls are in flight right now

Capacity planning has a blind spot: `GET /metrics` exposes a running total of how long-polls have ever resolved and how often they resolve early, but nothing shows how many `GET /jobs/{id}?wait=` calls are parked mid-wait right now, at scrape time. That's the one number that answers "how much concurrent long-poll load is this instance actually carrying" without reaching for a request-throughput rate that doesn't capture connection *occupancy* -- the thing that actually matters for "do I need another worker/instance."

POST /jobs' duration cap validates the wrong request field

`Settings.job_max_duration_seconds` exists so an operator can cap how long a single simulated job is allowed to run, independent of the schema's own hard 600-second ceiling -- e.g. lowering it during a capacity-constrained window, or because a real transcoder backing this API in production has its own SLA-driven duration limit. Right now that setting does nothing useful: the check compares the wrong field, so any operator who lowers it for capacity reasons and trusts it to actually protect their instance is unprotected -- clients can still submit jobs right up to the schema's 600-second hard ceiling regardless of what this setting says.

Progress reports 0% for the entire job, then jumps straight to 100%

Progress is the entire reason a caller polls a job at all instead of just waiting for a single "done" webhook -- it's what a progress bar, a "3 of 5 steps complete" label, or an ETA estimate is built on. Right now, every progress update reports 0% for the job's entire runtime, until a separate, hardcoded completion write jumps straight to 100%. A frontend showing this as a progress bar shows it frozen at the start for the whole job, then teleporting to done -- indistinguishable, to a user, from "this progress bar is broken" or "this job actually hung and then suddenly finished," either of which erodes trust in the product a lot faster than an honest, accurate 40% would.

Add GET /jobs to list/enumerate known jobs

The only way to find out anything about a job today is `GET /jobs/{id}` -- which requires already knowing its id. There's no way to answer "what jobs currently exist" or "what's running right now" through the API at all; today that means reaching for direct Redis access (`redis-cli KEYS 'job:*'`, or worse, `SCAN` in production), exactly the kind of direct-datastore access an API is supposed to make unnecessary.

GET /jobs/{id}'s wait clamp uses max() instead of min(), so wait is never actually capped

This single flipped function call breaks two guarantees the whole API is built around, at the same time. First, a `wait` above the server's cap is supposed to be capped at it -- with `max()` instead of `min()`, a caller asking for more than the cap gets exactly what they asked for, uncapped, so the entire proxy-safety mechanism does nothing. Second, a `wait` below the cap -- including 0, including omitting `wait` entirely -- gets silently forced up to the cap. `wait` being optional exists specifically so a plain status check never hangs; with this bug it always hangs, for up to `max_wait_seconds`. Any monitoring dashboard, health-check script, or simple client library polling the "naive" way silently turns into a long-poller itself, and a client library with a small connection pool making frequent "just check the status" calls would exhaust that pool under normal use.

idempotency_key is accepted on POST /jobs but silently ignored

`JobCreateRequest` already accepts an `idempotency_key` field, and `Settings.idempotency_ttl_seconds` already exists as a config knob for how long a key should be remembered -- but nothing reads either of them. Two `POST /jobs` calls with the same `idempotency_key` today create two entirely independent jobs. This is arguably worse than the field not existing at all: a client that reads the field's presence in the API schema and builds retry logic around it gets silent data duplication instead of a clear "not supported" error.

TTL selection is inverted between running and terminal jobs

This bug breaks the TTL mechanism in both directions at once. A job that's still actively running can disappear from Redis before it finishes, because it's getting the short result TTL (meant only for finished results) instead of the long pending TTL -- a client polling a long-running job would suddenly get 404s partway through, indistinguishable from the job genuinely having vanished. And a completed job's result sticks around far longer than configured, because it's getting the long pending TTL instead of the short result TTL -- a promise this project's own README documents as a "privacy/cleanup guarantee" for whatever's in a job's result, quietly broken for every single completed job.

Add POST /jobs/batch to submit more than one job at once

Submitting N jobs today means N separate `POST /jobs` round-trips from the client. For a caller that legitimately wants to kick off a batch -- e.g. transcoding every file in a folder someone just uploaded -- that's N times the network overhead and N times the places a partial failure can happen (job 3 of 10 fails to submit; now the caller has to reconcile which of the other 9 actually went through).

Webhook callback signature is computed over different bytes than the ones sent

Every job with a `callback_url` gets its result delivered there, HMAC-signed, specifically so a receiver can trust the payload wasn't forged or tampered with in transit. Right now the signature sent in `X-Signature` is computed over a different serialization of the payload than the bytes actually transmitted. Any receiver correctly implementing "verify the signature against the raw body you received" -- the only correct way to verify an HMAC -- will reject every single callback this service ever sends as unauthentic. This isn't a one-in-a-while flake -- it's a deterministic 100% failure rate for every integration built against this feature, the kind of bug that would only surface once a real client starts actually checking signatures instead of trusting the callback blindly.

Add POST /jobs/{id}/retry to resubmit a failed or cancelled job

There is no `POST /jobs/{id}/retry`. A client that wants to resubmit a failed or cancelled job today has to have kept its own copy of the original `duration_seconds`/`steps`/`callback_url` and issue a brand new `POST /jobs` from scratch -- and even if a route existed, it couldn't reconstruct those parameters on its own, because the job document doesn't persist the parameters it was submitted with at all. Once a job is running, its own original submission is already gone from anywhere the server can see it.

Cancelled jobs aren't real asyncio cancellations, just a status flag

This project's own README makes a specific, deliberate claim: cancelling a job is real `asyncio.Task` cancellation, not a status flag the simulated worker happens to also set. That distinction matters beyond API-response cosmetics -- imagine gating billing on whether a job was genuinely cancelled (`task.cancelled()`) versus completed some other way, specifically so a user who cancels their own job isn't charged for it. Right now, every "cancelled" job's underlying `asyncio.Task` actually reports as having finished normally. A billing check built on that ground truth would incorrectly treat every user-cancelled job as a normal completion -- and this is exactly the "looks right at the API layer, wrong one layer down" failure mode that black-box HTTP tests structurally cannot catch.

JobRegistry.notify() reintroduces a missed-wakeup race

The entire signature claim of this project -- long-polling costs far fewer requests than naive 1-second polling -- depends on one guarantee: a status change that happens while a `GET /jobs/{id}?wait=` call is parked wakes it up promptly, not after the full wait window. This bug reintroduces exactly the race the registry's own docstring describes and claims to avoid: a change that lands in the narrow gap between a caller reading "what should I wait on" and that caller actually starting to wait can be silently missed, forcing that request to sit out its full timeout instead of returning promptly. A caller experiencing this wouldn't see an error -- just occasional, unexplained slowness on an otherwise-fast long-poll, the kind of intermittent latency that's brutal to track down.

Add a configurable cap on concurrently running jobs

`POST /jobs` unconditionally spawns a worker task for every request, regardless of how many jobs are already running. In this simulated service that just means more concurrent `asyncio.sleep()` calls, but this project's own README frames the simulated "transcode" as a stand-in for a real, resource-hungry job (a real transcoder's CPU/GPU budget). A real backing implementation would have a hard concurrency ceiling somewhere -- worker processes, GPU slots, external API rate limits -- and nothing in this service protects it. A traffic spike, a buggy client retry loop, or just organic growth in usage would all hit that ceiling by simply overwhelming it, with this service doing nothing to prevent, queue, or even report on it happening.