🤖 fix(tasks): establish settlement for failed manual reawaken attempts

[ThomasK33]

Problem

A manual reawaken can publish an owned attempt, fail to start its send/resume, and restore taskStatus: interrupted without settling that owner. The send obligation discharges, but readAttemptOutcome remains indeterminate. Explicit Stop settles it; retries can inherit the monotonic unproven-lineage marker.

Evidence and scope

Observed by a native regression in taskService.attemptAdmission.test.ts on PR #4308's candidate f2b99328784d829dddb3659014df00068740eeab. This is retained baseline behavior, not a fixed finding. See #4308 (comment) and the approved plan's deferred owned-interrupted-without-settlement cases.

Acceptance

1. Correlate failure/no-work disposition to the exact reawakened attempt and prove no execution or publisher survives before settlement.
2. Do not infer settlement from sendMessage returning an error, resumeStream returning started=false, or a status string alone; preserve token/turn ownership.
3. Cover pre-admission failure, admitted preparation failure, no-work, concurrent Stop, and a superseding attempt. Preserve report metadata and monotonic lineage.

Follow-up trigger: a dedicated task-lifecycle change after the G1/G2 recovery stack, before extending automatic recovery to this currently indeterminate case. This issue remains open independently of PR #4308.

---

Generated with xum • Model: coder:bedrock-mantle-us-west-2/openai.gpt-6-astra • Thinking: xhigh • Cost: $726.91

[linear-code]

MUX-162