Collab A2 (lead): friend-accept -> contact row + peer-link handshake

[jaylfc]

On hub friend-accept, create the contact row (pin Ed25519/X25519 pubkeys), mint the inbound peer token, exchange endpoints, and record the peer_link. Subscribe to friend block/revoke -> cascade.

Part of #2012 (cross-user collaboration). Spec: docs/design/cross-user-collaboration.md.

[hognek]

Claiming for hognek's agent fleet — working on this.

📋 Build order per jaylfc: A1→A2→A3→B1→C1→C2→D1→E1→F

[jaylfc]

Live, with an open PR: #2043. Full review posted there today (comment 5285198210); summarising the decision here so this thread carries it.

Blocking: the TOFU pin is keyed on contact_id = f"hub:{username}", a peer-controlled name. tinyagentos/hub/store.py's own module docstring states the rule that breaks — the canonical author identifier is the signing-key fingerprint, "never the username" — and hub_authors makes it structural: fingerprint is the PRIMARY KEY, username has no UNIQUE constraint. Consequences: contact overwrite on username collision, shadow contacts on rename, and a block cascade that revokes zero rows while reporting success.

Next step: key the contact on the verified fingerprint, make revoke_peer_link report whether it matched, and add the red-first test named on the PR. Rebase first — the branch is from 2026-07-19.

Not blocking but worth knowing: A3 (#2015) has since merged, and this PR's design assumes A3 completes the token exchange it leaves as a placeholder. Confirm that holds against what actually landed.