Record which machine ran each model job

[aperson30]

Follow-up to #270/#271/#272. Nothing records which machine ran a job or whether it fell back to bdmap1; the only trace is a buffered log line that is lost on reboot. That makes "how often do workers fail?" and "is bdmap1's GPU staying clear?" impossible to answer from data. This adds a small, separate record.

What it adds

Each finished job (completed, failed or cancelled) appends one line to <sessions dir>/job_runs.jsonl:
model, status, ran_on (the machine(s)), fell_back (to the web host), duration_seconds, input_size_bytes, a short error, session_id, recorded_at. No user id and no IP address. The newest 5000 are kept.

python -m services.job_run_log <file> [days] summarizes jobs by outcome, model and machine, and the share that fell back to bdmap1.

Why it is safe

• It is a separate append-only file, not a job.json field or a database column, so nothing the site reads changes and there is no schema change.
• Writing is best-effort and never raises: a problem there cannot affect a user's job.
• ran_on bookkeeping in auto_segmentor only notes where each model command ran (a worker; this host; a fallback; a re-run after a worker failure). It never changes how a job runs.
• The in-memory entry is always dropped (in the job thread's finally) and is capped, so it cannot leak.

Changes

• services/job_run_log.py (new, stdlib only): the file, a loader and the summary.
• auto_segmentor: _note_run / pop_run_info, called where a model command finishes (worker, local, fallback, out-of-memory), and for MedIA-Agentic.
• gpu_workers.run attaches the worker that ran the command.
• api_blueprint: the job thread logs every way a job can end and always releases the entry.
• deploy/GPU_WORKERS.md documents it; CI runs the new tests.

Testing

• 17 new unit tests (file format and no user data, trimming, loader and summary, every routing outcome: worker, plain local, fallback, re-run after a worker failure, out-of-memory, non-model commands) plus a structural test that every exit of the job thread is logged and the entry is always released (api_blueprint cannot be imported without the app's dependencies in the unit-test environment). 107 pass with the existing GPU worker suite.
• Real run on the server (throwaway copy, real LesionSegmenter job): recorded ran_on: ["bdmap4"], 30 s, no fallback; the summary command read it back.

Rollout

Deploys with the next reload. The file is created on the first finished job.