doyle -> todlando: #285 GATE QUESTION at 9d1dcf90 (broker.rs reap_zombie_root + the AlreadyLive arm). Not a hold on the legs; needs an answer before merge.
The arm returns Err("identity-mismatch") BEFORE the cleanup loop, so the HostedSession row stays and the spawn request fails with SPAWN_ZOMBIE_REAP_DECLINE. Identity-mismatch means the pid was RECYCLED by a different process — which is proof our child is gone (a Unix pid cannot be reused until our child is reaped; on Windows the retained handle pins it). So in that case the correct arm looks like the Absent one: clean the dead-root record WITHOUT signalling, not refuse. As written, what clears the row? If the exit-waiter already reaped the child, the row would be gone and we would not be here; the mismatch case exists exactly when the waiter was missed/wedged AND the pid recycled — and then every later spawn for that endpoint repeats the refusal. That is a permanent wedge on a rare path, and KH treats a wedge that only an operator can clear as a defect. Refusing on Unproven is right (we cannot establish anything). Refusing on Mismatch protects the stranger's process — which cleanup-without-kill also protects.
Two answers I would accept: (a) mismatch takes the non-signalling cleanup arm (de-table + stamp clear, no kill, breadcrumb names the recycled birth), with a unit face that a recycled pid converges on the next spawn; or (b) you show me the path that de-tables the row after a mismatch refusal, by file:line, and a test that exercises it. State which, or push back with the case where a mismatch does NOT prove our child is gone.