fix(core): a ledger failure defers recording instead of displacing the receipt

[Max17190]

Why

Round-5 self-extensibility dogfood ticket T5 (.scratch/selfext-round5/findings.md): when a refreeze's ledger sync fails, ledger_changes returned ["ledger error: {e}"] as the receipt's what-changed slot, so the model-facing refreeze receipt opened with a bare error. That reads as if the refreeze itself had failed, when in fact activation never depends on the ledger (the new capability is live) and the claim stays queued for a later sync (persisted when the ledger directory allows).

Summary

• The failed-sync receipt line now states the three true facts before the error: the extension files changed, the change is still active, and the recording claim stays queued for a later sync, with the error in parentheses.
• No behavior change to activation, queueing, or the landed flag; this is receipt truthfulness only.

Test Plan

• New a_ledger_failure_reports_deferred_recording_not_a_bare_error: fails the sync deterministically by dropping a file at the ledger root (works under root too, unlike a chmod denial), asserts the receipt names the still-active change and the queued recording, and does not lead with the bare error. Shown red on the previous commit (the old line was exactly "ledger error: ...").
• Full core suite: 536 passed, 0 failed. Workspace clippy at zero warnings.

Greptile Summary

This change makes a failed capability-ledger sync clear to the model without implying that the capability update itself failed. The ledger-root-as-file failure path was exercised through the real refreeze flow: the capability became active, its Session recording claim remained queued, and the receipt stated that recording was deferred. The prior revision returned only a bare ledger error on this same path; the current implementation does not.

Confidence Score: 5/5

Safe to merge: the exercised ledger failure path preserves both capability activation and deferred recording state while communicating the outcome accurately.

A focused asynchronous harness ran the production refreeze path with a deterministic ledger filesystem failure, verified the emitted receipt and retained Session claim, and showed that the corrected behavior differs from the parent revision.

Files Needing Attention: No files need further attention; the reviewed behavior is contained in crates/core/src/agent.rs.

T-Rex Logs

What T-Rex did

• Ran an authored asynchronous Rust harness through the mid-turn refreeze flow using a ledger-file path and observed ACTIVE=live QUEUED=session.
• Compared with the prior revision, the current run preserved the active capability and the deferred-recording state, whereas the parent revision previously failed with a not-a-directory ledger receipt.
• Reviewed the receipt flow in crates/core/src/agent.rs, noting that activation precedes settlement and that the corrected receipt text resides at crates/core/src/agent.rs:2003-2018, and confirmed that no production files were modified; evidence artifacts were created to document this.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix(core): a ledger failure defers recor..." | Re-trigger Greptile}