fix(signals): re-running a failed implementation task ignores a later already_addressed verdict

Problem

already_addressed is enforced when an implementation task is created, never when a failed task is re-run.

products/signals/backend/auto_start.py (maybe_autostart_implementation_task, the skip_reason block near line 628) refuses to create an implementation task when the latest ActionabilityAssessment.already_addressed is true. The re-run path goes through products/tasks/backend/facade/api.py run_task, which calls enforce_report_implementation_rerun_cap (products/signals/backend/task_run_artefacts.py). That check only asks whether another task holds the report's implementation slot. It never re-reads the actionability artefact.

A task whose run failed without a PR has released the slot, so its re-run passes. In one case an implementation task created on day 1 failed with a gateway 402 admission rejected. On day 5 the report was re-researched and judged already_addressed: true, with a verdict that explicitly said to review and land the existing PR rather than open a competing one. On day 6 the day-1 task was re-run, ignored that verdict, and opened a second PR (#89054 alongside #88072).

Fixes

1. In enforce_report_implementation_rerun_cap, after confirming the task is an implementation, load the report's latest actionability_judgment artefact (_latest_artefact_as in auto_start.py already does this lookup; reuse or lift it) and raise ReportTaskCapExceeded with a clear detail ("This report was judged already addressed on ; open the existing PR instead") when already_addressed is true.
2. Apply the same check to any other re-run entry point that reaches run_task for signal_report tasks (there are two call sites in products/tasks/backend/facade/api.py, near lines 6557 and 6917).
3. Keep the "my run failed, try again" path allowed when the latest verdict is still already_addressed: false.
4. Test: report with an implementation task whose runs all failed; append an actionability_judgment with already_addressed: true; run_task on the old task must refuse. Add it next to the existing rerun-cap tests.

Why

A dispatch decision from six days earlier should not outrank a fresh verdict that names the competing PR. The fix is a single read in the function that already locks the report row for exactly this kind of decision.

From this Slack thread; the investigation is written up in the self-driving-debugging skill in the skills store.

Start in products/signals/backend/task_run_artefacts.py at enforce_report_implementation_rerun_cap, then inspect the two run_task call sites in products/tasks/backend/facade/api.py and the existing rerun-cap tests. Confirm how auto_start.py loads the latest actionability_judgment artefact. Done means a failed implementation task is refused when the latest verdict is already_addressed, while reruns remain allowed when it is false.