fix(pack): only a warrant this lead signed may depose it
A peer left pack A as its armed deputy at warrant generation 3. `leave` dropped the secret and the pins and kept `deputy`, `warrant` and `standbyRoster`, so the machine reported generation 3 on `hello` in pack B. Pack B's new lead had never minted a warrant, read 3 > 0 as a takeover it had missed, parked itself `no-proof` and took its own front door down. Recovery was by hand on two machines. Three changes, in the order they close the failure: * The boot gate deposes on a PROOF only. A warrant that verifies against this machine's own certificate deposes it, exactly as §18.12's "what counts as learning" already says. A bare generation ahead, a conflict with no warrant, and a warrant for another pack all warn once and the lead keeps publishing. This is narrower than §18.11 as written, and the deviation is argued in the module header: fail-closed on an unproven claim turns one peer's stale file into the pack's outage. * `leave` clears every deputy field, and removes `standby-devices.json`. The generation counter's "never resets" rule is scoped to a pack, and this machine is leaving one; carried across that boundary it is not a replay defence but a claim about a pack it no longer belongs to. * `pack remove <member>` drops the designation when it names that member, so `pack status` stops printing a deputy that `pack deputy --revoke` cannot find. The warrant stays, because the counter must not walk backwards inside a pack. Plus a belt-and-braces boot check on the peer: a stored warrant stamped with another pack's id is discarded, with the deputy fields that rode with it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A
Altan Sarisin committed
bd7e3b5e50a49bcd5842c9bf50d2ef30699cea47
Parent: a2ee186