fix(llc): surface the persisted skip reason in the heartbeat monitor (#12681)

[mrveiss]

Refs #12681. Deliberately not Closes — this is one of three items the issue
covers; see "What this does not fix".

Thinking Path

#12681 reports that setup-wizard provisioning fails invisibly. Tracing where the
information is actually lost changed the fix.

A heartbeat that never dispatched raises HeartbeatDispatchSkipped, and the
scheduler already handles it deliberately — it records SKIPPED and stores
exc.reason:

except HeartbeatDispatchSkipped as exc:
    final_status = LLCRunStatus.SKIPPED.value
    error_msg = exc.reason

_run_to_dict already returns that field, so the reason survives all the way to
the client. It was never displayed: the component's AgentRun interface did not
declare error, and the run row rendered only status, date and duration.

So this is not a missing-plumbing problem. The reason is persisted, served, and
then dropped one line short of the screen. Every skip therefore looked identical
— a missing adapter binary, an active cooldown, and an agent with no work were
indistinguishable without querying the database directly, which is precisely the
"fails invisibly" symptom the issue describes.

I also found SKIPPED has no status colour: .status-skipped was never defined,
while queued, running, failed, timed_out and unknown all are. The one
status whose entire meaning is "this did not run" rendered as unstyled text.

What Changed

• AgentRun declares error?: string | null.
• The run row renders a reason line when the run carries one, labelled by status
  so a SKIPPED run is not misread as a crash.
• .status-skipped styling added, matching the existing status colour scheme.
• skipReasonLabel / errorLabel added to all 11 locales.
• Three component tests.

Verification

The tests mount HeartbeatMonitor and drive it through the real path
(fetchAgents → click row → openHistory → render), rather than asserting on
the response shape. That distinction is the point: the field was already present
in the payload, so any test written against the API would have passed for the
entire time the defect was live.

• skipped run with a reason → .run-reason present, contains the reason text
  and the skip label
• failed run → carries the error label, not the skip label
• completed run with error: null → no .run-reason element

The third is the control. Without it the first two would still pass if the row
were rendered unconditionally, which would put an empty label on every run.

Locale edits were made structurally and verified to be exactly two added lines
per file (11 files changed, 22 insertions(+)), with each file confirmed to
round-trip byte-for-byte beforehand so no reformatting is smuggled in.

Not verified locally: the frontend suite is not run here, so the component tests
are verified by CI, not by me.

What this does not fix

#12681 covers three independent items. This is item 3 only.

Item 1 — nothing installs the claude CLI onto the service PATH — and item 2 —
llc/api/agent_hires.py validates that an adapter type is registered but never
that it is available, so a hire can succeed for an adapter that cannot run —
are both untouched here.

Those two are sequenced: item 2 must not land before item 1. Today an
operator can hire an agent and hand-install the CLI afterwards. Rejecting the
hire first, while nothing installs the binary, would make provisioning strictly
worse rather than better.

This item is independent of that ordering, which is why it goes first.

Model Used

Claude Opus 5

[github-actions]

✅ SSOT Configuration Compliance: Passing

🎉 No hardcoded values detected that have SSOT config equivalents!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!