[Bug]: Full and merge settlement sweeps can still settle a thread whose awaited background work just ended, if the event consumer lags #29899

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Found by reading the code while writing #29820, and not reproduced live:

1. A thread awaits a background task with t3_background_wait, and its PR has merged, or its inactivity window has passed.
2. The task finishes and the provider thread's roster empties.
3. The settlement event consumer is behind when a full or merge sweep runs.

Expected behavior

The thread is not auto-settled until the turn that reports the finished work has been requested, as #29820 does for the incremental sweep.

Actual behavior

#29820 fixes #26083 by recording, from the domain event stream, when a provider thread's roster stops holding work, and holding settlement until the report turn. Full and merge sweeps read the projections directly. If the event consumer falls behind, those sweeps can see the empty roster before the hold is recorded, and they settle the thread and detach the session. Closing this needs the time the work ended stored in the projection.

Impact

Minor bug or occasional failure

Version or commit

main at d8a829e, plus #29820

Environment

Linux x86_64, T3 Code server running as a service, Claude provider (claude-opus-5-5)

Written by Claude Opus 5.5 in Claude Code, run from T3 Code.