Surface bridge worker job failures as comments on the tracking issue to close the silent-crash feedback gap

[arndvs]

Summary

When the bridge worker's _process_job raises an unhandled exception (subprocess crash, timeout, workspace error), the failure is recorded in SQLite and emitted as a HUD event — but no external signal reaches the PR author or tracking issue. The PR sits indefinitely waiting for a fix that will never arrive, with no visible indication that the autonomous attempt failed.

This is the bridge-worker analog of the CI-side "silent failure-reason loss" fixed by #155, but in the persistent-process path that handles agent:fix events via the webhook→worker pipeline.

Context

• bridge/worker.py process_one_job() catches exceptions in two paths: WorkerShutdown (intentional) and generic Exception (crash).
• On generic failure: db.mark_failed(conn, job.id, traceback) + hud.emit("bridge.job.failed", ...) — both internal-only.
• The tracking issue (created/updated in step 5 of _process_job) remains open with its last-known content. No comment indicates the attempt failed.
• The PR receives no label change, no comment, no re-request — from the author's perspective, nothing happened.
• The only existing outward signal is agent-loop-exceeded (iteration cap), which fires in a completely different code path and only on cap exhaustion, not crashes.

Problem

A developer relying on the agent:fix label expects either (a) their PR threads get resolved, or (b) they learn the attempt failed so they can fix it manually. Today, path (b) is invisible unless they check the HUD or bridge logs — artifacts most users never see.

Proposal

Add a failure notification step in the except Exception handler of process_one_job():

1. If a tracking_issue_number was recorded on the job (step 5 succeeded), post a comment:

   ⚠️ Bridge worker failed to complete this job.
   
   **Error:** <one-line summary, not the full traceback>
   **Delivery:** <delivery_id>
   
   The autonomous fix attempt did not produce commits. Manual intervention is needed, or re-trigger by adding the `agent:fix` label again.
   

2. Add the agent:blocked label to the tracking issue (consistent with CI failure behavior).
3. If no tracking issue exists yet (failure in steps 1–4), post a brief comment on the PR itself via the REST API, so the author at minimum sees that the bridge attempted and failed.

The failure comment must:

• Never include the full traceback (may contain tokens/paths).
• Use the already-minted token (which may have expired — guard with try/except and log if notification itself fails).
• Be idempotent: if the job is retried and fails again, don't stack duplicate comments (use a marker string or check for existing failure comments).

Non-goals

• Automatic retry of failed jobs (separate concern; today they stay failed permanently).
• Surfacing the full traceback externally (security risk).
• Changing the HUD event schema (HUD remains the detailed internal log).

Acceptance criteria

• On job crash with a tracking issue: a comment appears on the tracking issue with error summary + agent:blocked label.
• On job crash without a tracking issue: a comment appears on the PR with error summary.
• Failure notification is best-effort: if the token expired or GitHub is unreachable, the notification fails silently (logged, not re-raised).
• No credential or path information leaks into the public comment.
• Duplicate-comment guard prevents stacking on repeated failures for the same PR.
• Existing bridge.job.failed HUD event and db.mark_failed behavior are unchanged.

Affected files

• bridge/worker.py — process_one_job() exception handler
• bridge/github.py — may need a comment_on_pr() helper (or reuse comment_on_issue with PR number)

Relates to

• Extract Sandcastle workflow lifecycle into composite actions to eliminate 7× boilerplate and fix silent failure-reason loss #155 (closed) — CI-side silent failure-reason loss (same problem, different path)
• Close the HITL deferral loop: reconcile shft/hitl review issues on PR merge/resolution #306 — HITL deferral loop reconciliation (tangential: both deal with issue lifecycle)
• ADR-006 — Decision Ledger: a crash-and-notification is a decision.blocked event; this work makes it externally visible, complementing the internal persistence proposed there.