A failed probe of the running front door spawns a second door beside it #370

ensureFrontDoor probes the running door's provider listener over TLS with a 2 s timeout, and on any failed probe it distrusts that supervisor and spawns a replacement beside it. The old door is never stopped, so a transient failure (a slow answer while many sessions reattach at once, say) leaves two doors alive. The replacement finds the sticky ports held and moves every listener, the direct one included, which strands every provider launch routed through headroom (#367) and leaves sessions on the old door unreachable from the new address.

Seen twice on one day on a machine running a few dozen sessions: each new door was spawned beside a live one, and the second of them ten seconds after a launch started. The door log shows the sticky-port moves but not why the probe failed, so the rejection reason should be logged when a supervisor is distrusted.

A failed probe should be retried with backoff before it is believed. If the listener is still unreachable, the unauthenticated supervisor is stopped (it has already been distrusted) or the launch is refused with the reason; spawning beside a live door is the defect. The probe's timeout alone is not the fix, since the next slow start spawns a duplicate anyway.