fix(shutdown): flat post-exit pause and a budget sized from measurement

[AThraen]

Two problems, both found by running it rather than reasoning about it.

1. The adaptive gate overshoots at shutdown too

#111 reverted the config-watching gate on the launch path but kept it at shutdown, on my reasoning that "the machine is quiet at shutdown, so polling is reliable there."

Measurement falsified that:

SHUTDOWN 'SiteAnalysis': exit=4656ms  cfgSettle=8731ms

against a 1000ms cap — 8.7× over, and 56% of the entire shutdown budget spent in a single session. That's what forced the remaining six to be killed with no exit wait.

Same disease as the launch path: when the thread stalls, the gate measures the stall rather than the file. With sessions actively dying, shutdown isn't quiet either. I kept the half of the revert I liked and it had the same bug.

Now a flat Task.Delay, on both the shutdown loop and the restart path. Recomputing that run flat: 8969ms instead of 15506ms, nothing force-disposed. The gate's typical ~300ms beats a flat 1000ms right up until it doesn't, and the tail is what costs.

ClaudeConfigGate now has no callers and is deleted along with its tests, rather than left as dead code for someone to reintroduce.

2. The budget was sized from the wrong data

15s was chosen when the only measurements available were idle sessions exiting in 460–770ms. Busy sessions measure 2.3–4.7s each, so nine of them need roughly 30s — and 15s force-disposed over half the fleet on an ordinary close.

Raised to 30s. A clean exit lets Claude finish writing its config, and ShutdownOverlay is already on screen explaining the wait. The budget exists to bound a genuinely wedged session, not to hurry a healthy one.

Confirmed: the #115 HasExited fix works

No exit= value is anywhere near the 10s cap — max observed 4656ms. Nothing is timing out on a process that already died, which was the entire point of that fix. The remaining cost was genuine slow exits plus the gate overshoot above.

Docs

The gate is recorded as gone from both paths, with the falsified reasoning written down. ClaudeShutdownBudgetMs carries its measurements and a note to re-measure exit= before shrinking it — the summary line alone cannot distinguish "slow exits" from "waits that aren't returning", which is exactly the ambiguity that cost a round here.

Check	Result
Unit tests	304/304 (10 fewer — ClaudeConfigGateTests deleted with the gate)
App + Tests build	0 errors, 0 warnings

🤖 Generated with Claude Code

https://claude.ai/code/session_01NDsEfog5kVkT5NmX1Ya5be