Live CLI replay handoff: lingering DEVICE_IN_USE claim and stale-close artifact rewrite (split from #1384)

[thymikee]

Split out of #1384 per review on #1390: #1390 fixes the session-vanishes-after-a-close-less-replay symptom, but two other symptoms recorded in #1384's original report are not verified fixed by that change and shouldn't ride along to auto-close under it.

1. Lingering DEVICE_IN_USE right after close

After closing a recording session, the immediate next replay can fail step 1 with DEVICE_IN_USE ("Device is already in use by session "default"") until a second explicit close --session default — a lingering claim/lease after teardown. Cf. the daemon-shutdown releaseSessionLease gap noted in the device-claim design.

2. Published-artifact rewrite under interleaved closes

One interleaved sequence of closes across a stale replay session + a PUBLISHED recording session left the published .ad rewritten with post-publication actions and two trailing close lines. PUBLISHED close-time saving is supposed to be disarmed (ADR 0016); the clean publish→get→close flow is hash-stable and verified, so this looks specific to the interleaved-stale-session case. Timeline available in the #1381 validation notes referenced from #1384.

Scope

Both need their own live-repro verification (real daemon over CLI, not the in-process provider harness) before a fix — the same category of client/IPC-layer gap #1384 turned out to be for the close-less case.

[thymikee]

Triaged as bug + needs-info. Before this is agent-ready, please attach a minimal live-CLI reproduction for each symptom: exact open/close/replay commands (including session and state-dir), the relevant request/daemon logs and advisory-claim state for the lingering DEVICE_IN_USE, and before/after hashes plus the exact interleaved-close timeline for the published-artifact rewrite. If the two symptoms reproduce independently, split their evidence so they can be fixed and closed separately.