[P2P epic] Phase 4 — signed ops + peer-enforceable epoch fence

[cuttlefisch]

ADR: ADR-026. Phase 4 of 6. Hard prerequisite: #72 (unpredictable epoch token). Depends on: Phase 3.

Make the ADR-023 epoch fence peer-enforceable so removed-member / pre-grant-cascade writes are rejected at every peer, not just the doc-owning daemon.

Scope

• Sign content (node) ops with author fingerprint + epoch + Ed25519 signature over the op bytes.
• On each peer: read the signed membership chain (Phase 3) for the author's current epoch, then apply ADR-023's rule locally — every new op (beyond the peer's node SV) must be under the author's current-epoch derive_kb_client_id(fp, epoch), else fence (rebase). The ADR-023 viewer_era_* oracle, now peer-side.
• Blocked by collab(security): epoch-fence hardening — unpredictable daemon-issued token + persist epoch across remove/re-add (ADR-023) #72: peer-side fencing is only sound with an unpredictable epoch (otherwise the ADR-023 "pre-rotation attack" defeats it).

Observability (ADR-027)

fenced_ops + sig_verify_fail counters; fenced-op + verification-failure events surfaced via the notification bus.

Verification

Unit: peer-side fence parity with ADR-023; signed-op author/epoch verify; replay/mis-attribution rejected. Security-negative mesh e2e: a relayed stale-epoch op is fenced by the receiving peer without a trusted server; removed-member writes don't cascade.

---

🤖 Phase epic for the P2P decentralized KB-sync initiative (ADR-025/026/027, plan: daemon-mediated mesh, integrity-first, observability throughout).

[cuttlefisch]

📎 Design: ADR-026 — needs prerequisite #72 · ADR PR #95 · part of #96 (P2P tracking).

[cuttlefisch]

Active — this is the tracking issue for the current priority (P2P content integrity, Phase 1b of the reconciled roadmap). Not yet delivered. Prerequisite #72 (unpredictable epoch) is met (merged). Phase 2b delivered the membership op-log + per-peer derivation this builds on; this issue covers the content (node) op counterpart: sign each sync/update with author Ed25519 + epoch, peers verify author ∈ derive_valid_members(...) at the op's epoch on apply (peer-side ADR-023 fence). Design doc = new ADR-036 (signed content operations). Verification includes the cross-daemon forged-content + forged-membership oracle (the item folded over from #90).

[cuttlefisch]

Test-rigor note (from the coverage audit). The membership test helper hardcodes epoch: 0 on every op, so the ADR-023/§A5 epoch fence is inert in all current tests — a regression breaking epoch consistency (or the peer-side fence) would pass silently. The signed-content-ops work here MUST exercise the fence with varying, realistic epochs (a role-change/re-admit bumps the epoch; a content op authored under a stale epoch is fenced). Plus the cross-cutting rigor just demonstrated in #135: concurrent branches + shuffled apply order, not linear hardcoded chains. And the real-mesh forged/mis-attributed-content oracle (not just synthetic unit inputs).