Completed jobs increment the "failed" metric, not "completed"

jobs_finished_total{status=...} is the metric anyone would reach for to answer "what fraction of transcodes are failing right now" -- the kind of number that gates a deploy, drives an alert threshold, or shows up on the first panel of an on-call dashboard. Right now, every single job that completes successfully increments the "failed" bucket instead of "completed". In a healthy system processing thousands of successful jobs a day, this metric would show a 100% failure rate. Best case, whoever's watching that dashboard loses trust in it and starts ignoring it -- so the day this service actually starts failing for real, nobody notices. Worst case, it pages someone at 2am for a "failure spike" that is, in fact, every job succeeding normally.

This line runs immediately after the job's success _transition(..., status="completed", ...) call -- exactly when the job succeeded -- but increments the counter under the "failed" label instead of "completed".

1. pytest practice_tickets/tests/test_ticket_01_completed_jobs_counted_as_failed.py -v
2. Or manually: submit a job via POST /jobs, poll GET /jobs/{id}?wait=1 until status == "completed", then read .

This is a copy-paste-style mistake: the success branch's metrics call almost certainly started as a copy of the except branch's (or vice versa), and the label literal never got updated to match which branch it's actually in. Nothing in the type system or a linter catches a wrong string literal passed to .labels(status=...) -- it's valid Python, valid Prometheus, and only wrong in meaning. run_job() has three near-identical .labels(status=...).inc() call sites (success/cancelled/failed) -- one of them is wrong, and eyeballing them side by side is the fastest way to spot it.

Look at all three jobs_finished_total.labels(status=...) call sites in app/worker.py's run_job() (success, cancelled, failed branches) side by side. One of them doesn't match the branch it's in.