Module guard 

The pid-file guard: the live handle on this incarnation’s claim.

The guard is created by the birth claim and held for the whole run scope. Three things go through it:

1. Stage writes while the boot works — see super::stage, whose reporter shares this guard’s record handle so the guard’s own copy is always the one on disk.
2. The bind-time fill: the bound addresses, the resolved drain window, and state = Serving.
3. The drain flip: state = Draining, written from the signal path before the drain itself runs, so a successor’s birth claim sees a drainer to SUCCEED rather than a server to refuse.

Every one of them is a compare-and-write under the pid mutation lock: read the file, verify it still holds THIS incarnation, apply the change, write atomically. A record that has been replaced by a successor is never overwritten — the update warns and skips, exactly as the guard’s Drop leaves a successor’s file alone.

Drop removes the file only while it still holds this INCARNATION — the identity compare, never whole-record equality, because the record mutates throughout the incarnation’s life (see the super::pid_file module ruling).

Structs

PidFileGuard

Removes the pid file on drop — but only while the file still holds this guard’s INCARNATION, so a lingering guard can never delete a successor’s claim.

Enums

RecordUpdate

The outcome of an attempted update of this incarnation’s own record.