Allocate IPv4 addresses and keep them, as signed state

Derived IPv4 addresses could not survive anything: they changed with the
range, and there was no way for a member to come back to the one it had.
Addresses are now allocated and recorded as signed facts, which is the
first slice of the model in docs/sync-model.md.

src/state/ holds one record per author per network, carrying that author's
complete current statement, signed with its persistent device key over a
length-prefixed canonical encoding. Merging follows the model's rules: a
higher version wins, an older one never rolls back a newer, duplicates are
idempotent, absence from a snapshot is not deletion, and a same-version
conflict is resolved identically on every replica and reported rather than
letting replicas diverge. Records are persisted in state.sqlite, with the
record and the author's version counter committed in one transaction
before anything is announced, and distributed as a State control message
that is merged into what the receiver already holds.

No vote, deliberately, despite the request. A majority is not a trust root
here — anyone with the secret can mint identities — and a quorum would
stall with one peer online and diverge across a partition. Signatures plus
a deterministic merge converge without either failure mode: two members
claiming one address at once are resolved by the lower endpoint id, and
the loser allocates again with a higher version.

The range moved from the plugin to the agent, defaults to 10.13.37.0/24,
and is now agreed rather than configured per member: a joining agent
adopts what the network already uses, so --ipv4-range only matters for
whoever starts it. The announcement went back to identity only (version 3)
since the range travels in signed records now.

A release tombstone exists and merges correctly, but nothing emits one
yet.

116 tests. The headline ones: an address survives restarting both agents,
three members get three distinct addresses, and a member started with a
different range adopts the one in use. Confirmed by hand with two CLI
agents restarted end to end.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/sync-model.md

@@ -1,10 +1,13 @@
 # Planned state synchronisation
 
-**Nothing in this document is implemented.** The proof of concept exchanges
-hostname and capability announcements over live sessions and keeps no
-replicated history. That is also why WireGuard peer membership is
-session-scoped today: a peer leaves the overlay when its control session ends,
-because there is no agreed durable state to keep it. This file records the intended direction so the module
+**The first slice of this model is now implemented**, in `src/state/`, and is
+used for one thing: IPv4 overlay addresses. What follows describes the whole
+model; the section at the end says exactly which parts exist.
+
+The proof of concept still exchanges hostname and capability announcements
+over live sessions and keeps no replicated history for those, which is why
+WireGuard peer *membership* remains session-scoped even though a peer's
+*address* no longer is. This file records the intended direction so the module
 boundaries in [architecture.md](architecture.md) stay compatible with it, and so
 nobody mistakes the current announcements for synchronisation.
 
@@ -72,6 +75,31 @@ migrations for this.
 - Anyone who knows the secret can author records, so a majority of records is
   not evidence of anything.
 
+## What exists today
+
+Implemented, in `src/state/`:
+
+* signed records, one per author per network, each holding that author's
+  complete current statement rather than a delta;
+* signing and verification with the persistent iroh device key, over a
+  length-prefixed canonical encoding;
+* the merge rules above: higher version wins, an older version never rolls
+  back a newer one, duplicates are idempotent, a same-version conflict is
+  resolved identically on every replica and reported;
+* a release tombstone, which merges correctly and is not undone by a replica
+  that has not heard of it — though nothing emits one yet, so freeing an
+  address still means forgetting the network;
+* persistence in `state.sqlite`, with the record and the author's own version
+  counter committed in **one transaction before the record is announced**;
+* distribution as a `State` control message, merged into what the receiver
+  already holds rather than replacing it;
+* allocation of a free IPv4 address against what everybody else holds, which
+  is what makes an address stable across an absence.
+
+Deliberately not implemented: compaction, revoking a whole author, record
+types beyond addressing, and any bound on how large a snapshot may grow
+beyond the per-message limit.
+
 ## Future tests
 
 These are **not implemented and must not be reported as passing**: