🤖 fix: clarify unrelated-message acceptance for missing-checkout recipients

[ThomasK33]

Problem

Track the early-readiness/acceptance inconsistency raised in PR #4273 review r4056679943.

A worktree can retain consent after archive-with-checkout-deletion and unarchive. Its derived metadata is transcriptOnly, but the raw runtime still classifies as worktree. The peer session path can durably append an envelope and trigger before runtime preparation discovers the missing checkout. The runtime then emits runtime_not_ready; that error is transient rather than a persisted failed-assistant row.

This is not a demonstrated provider-spend bypass. Keep the accepted/history inconsistency distinct from the stronger allegation.

Evidence and limits

Source tested: b4d959354c35d8dc2cd4c23f0507c7bec5e1c4c8.

A focused temporary test used real Config, HistoryService, AgentSession, AIService, TurnRequestBuilder, ProviderService and WorktreeRuntime, with the peer broker's prepared envelope and the background-send options used by TaskService. All outbound fetch calls were intercepted in-process; no network request left the test.

Scenario	Session result	Durable rows	Runtime outcome	startStream / fetch
Registered checkout exists	Accepted	Peer envelope, trigger, failed assistant row	Ready; deterministic fake 401	1 / 1
Registered checkout missing	Accepted	Peer envelope, trigger	Terminal runtime_not_ready	0 / 0

The positive control and missing-checkout case passed together three times, two tests per run. This is a real session/runtime-path test, not an end-to-end execution of TaskService's admission/budget handling or WorkspaceService's pricing/queue decision. Those outer paths were source-traced only. The final task-tool return and quota-refund behavior need explicit coverage in this follow-up.

transcriptOnly is derived frontend metadata, not persisted authority. The existing runtime gate prevents commands/provider execution on the missing repository; the observed gap is admission/acknowledgment and transcript consistency.

Proposed scope and acceptance

1. Define whether a known missing-checkout recipient must refuse before peer rows are persisted, and specify the sender-visible result.
2. Add a deterministic full TaskService → WorkspaceService regression using real history and the missing-checkout runtime; assert persistence, result, and quota/refund behavior. Retain a valid-checkout positive control.
3. If early refusal is required, use the target-specific send/admission path. Do not add per-candidate filesystem probes to the synchronous instance-discovery predicate, a new persisted permission field, or a generic readiness subsystem.
4. Preserve default-off consent, generation revocation, local/worktree boundaries and the existing fail-closed runtime gate.

Owner: @ThomasK33. Follow-up trigger: the next peer-admission or missing-checkout handling change, or a dedicated acceptance-consistency fix. Deferred does not mean fixed; this issue does not waive the remaining PR reviews or CI.

---

Generated with xum • Model: coder:openai/gpt-6-astra • Thinking: xhigh • Cost: $1177.45

[linear-code]

MUX-160