SIGN IN SIGN UP

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