fix: decide a reclaimed delivery on the wake outcome alone

[apresmoi]

Follow-up to #29, from an adversarial review of a defect six rounds of targeted fixes failed to converge on.

The defect

The post-wake decision — is this delivery deferred (what the agent did) or reclaimed for restart (what the runtime did) — keyed on this.stopping || result.status === "stopped". Only the second is a wake outcome; the first is a host-lifecycle flag.

So a wake that completed had its evidence discarded because the dispatcher happened to be halting, and the delivery was recorded accepted, deferred: false, execution_id retained, no code — a record byte-identical to "never ran" and to "ran but forgotten".

Production tolerates this because a restart re-delivers and the agent redoes the work. A one-shot trial cannot, and the ambiguity is why six rounds of naming causes could not converge.

dispatcher.halt() runs before host.stop(), so the only case the flag uniquely covered was a wake that resolved on its own merits during the halt — precisely the evidence being lost.

The change

Remove this.stopping from the post-wake condition; the wake result alone decides. The pre-wake guard is untouched. This is a removal, not a mechanism.

A test added in the previous round asserted the defective behaviour and has been inverted: a completed wake under a halting dispatcher now records deferred: true.

Verification

Suite 878 pass / 0 fail. Verified by executing the shipped dispatcher in both images: the previous build records deferred: false with the execution id retained, this one records deferred: true with it cleared. A wake that returns stopped is still reclaimed with its code recorded.

🤖 Generated with Claude Code