fix(registry): free a job cancelled in the pop-to-claim window, and boot with a bad registry

[thcp]

Fixes #520. Prerequisite for #521 -- that fix builds on restore()'s hardening here.

1. A cancel in the pop-to-claim window stranded the job forever

The worker pops at jobqueue.py:213 and only claims with _set_running() at :229. In between, the job is in neither the queue nor the running slot.

A cancel landing there:

1. cancel_job sets cancel_requested = True
2. jobqueue.discard() returns False -- already popped -- so it never sets status="cancelled", never calls cleanup_job_dir, never persists
3. running_id() is still None, so the terminate branch is skipped
4. The worker sees the flag and continues -- "drop it silently"

The job stayed at "queued":

• Permanent capacity loss -- pending_count counts status == "queued", so register_if_capacity counts it forever
• Invisible -- not in _queue, not running, so absent from the queue view
• Disk never freed -- a queued upload holds its source, up to 400 MB
• Resurrected every restart -- "queued" is in _RESUMABLE, hence _PERSISTED

The worker is the sole consumer and owns the job once popped, so it now finalises the cancellation itself. Extracted as _finalise_dropped_job() rather than inlined, so the drop path is directly testable and so an already-terminal job is explicitly left alone rather than having a real result rewritten.

2. A malformed registry.json stopped the backend booting

restore() caught (OSError, json.JSONDecodeError, TypeError, ValueError). A registry.json that is valid JSON but not an object -- [1,2,3], null, "a string" -- makes _migrate call data.get() and raise AttributeError, which that tuple does not name.

restore_registry(JOBS_DIR) runs at module scope in app/main.py, so the import fails and the backend never starts. No self-healing, no user-visible recovery short of deleting the file by hand.

Orphan recovery and the trailing persist() sat outside the try entirely, so an unreadable jobs_dir was fatal at startup for the same reason.

Both are now caught broadly and logged. A registry we cannot use should cost the user their job list, not their app.

Verification

New tests/test_registry_resilience.py, 11 tests.

Confirmed not vacuous, both halves independently:

• Reverting the worker's _finalise_dropped_job call -> test_cancel_between_pop_and_claim_finalises_the_job fails
• Reverting restore()'s except back to the tuple -> 5 tests fail

The cancel test deliberately drives the real _worker_loop rather than calling the helper, so it also catches the worker simply not calling it -- an earlier draft called the helper directly and did not catch that.

ruff check       All checks passed
ruff format      94 files already formatted
pytest tests/    904 passed, 2 failed

The 2 failures are test_stems_api.py::test_all_stems_zip_ogg and ::test_ogg_is_still_streamed, which fail identically on 0.16.1 without this change (verified on the base branch). Local ffmpeg without libvorbis, most likely -- unrelated, and not filed.