docs: ROADMAP.md and KB_SHARING.md cite closed/shipped items as still-open

[cuttlefisch]

Source: hub-model shared-KB readiness review — cross-checked every "known gap"
claim in the docs against gh issue view / CHANGELOG.md before concluding drift.

What

Two confirmed instances of docs describing shipped/closed work as still pending:

1. ROADMAP.md:28,473 — still lists #78 (doc-store eviction TOCTOU) as an open
   unchecked item (- [ ]). #78 is closed, resolved as stale: evict_idle
   already re-checks connected_clients == 0 under the write lock before removing a
   doc (daemon/src/doc_store.rs:507-512), landed in feat: v0.10.4 — collaborative editing protocol + CRDT sync hardening #30 (7e200e3f) — confirmed via
   the issue's own closing comment.

2. docs/KB_SHARING.md:67,146,156 — describes the unified epoch fence (ADR-023/026)
   as "hardening... moving to [per-peer]" / "in flight." It has shipped: #157 is
   closed, CHANGELOG.md:509 confirms ("Unified op-log epoch fence on every write path
   (ADR-023/026: unified op-log epoch fence — derive role+epoch on every write path (A1+N1, HIGH) #157 A1+N1) (fix(daemon): unified op-log epoch fence on every write path (#157 A1+N1) #163)"), and enforce_epoch_fence/enforce_epoch_fence_with_coll
   (daemon/src/collab_handler/mod.rs:1013-1073) is confirmed in code as the single
   fence used by both the hub write path and the mesh dialer relay.

Why it matters

Low risk on its own, but a reviewer or new contributor trusting either doc over the
code/issue tracker could misjudge what's actually enforced or fixed — worth fixing
alongside a broader sweep, since this is the second time in this repo's history a
doc/code drift on a security-relevant claim has turned up (see the round-6 docs
housekeeping pass that fixed a similar "in flight" staleness for the same #157 in
CLAUDE.md before it was cross-linked here too — this issue is the KB_SHARING.md-specific
recurrence CLAUDE.md's own fix didn't happen to touch).

What's needed

Straightforward text fixes in both files reflecting the current (closed/shipped) status,
matching the wording CHANGELOG.md/the issues themselves already use.

Size: XS.

[cuttlefisch]

Both confirmed already fixed (verified fresh, not assumed):

1. ROADMAP.md — the daemon: fix doc-store eviction TOCTOU (last-client-leaves race) #78 line is already - [x] (checked/closed), not - [ ] as this issue originally reported: "Doc store eviction TOCTOU → daemon: fix doc-store eviction TOCTOU (last-client-leaves race) #78 (closed — stale, already fixed): `evict_idle`... already re-checks `connected_clients == 0`..." Issue daemon: fix doc-store eviction TOCTOU (last-client-leaves race) #78 itself is CLOSED.

2. KB_SHARING.md — no longer describes the epoch-fence hardening as "in flight." Current text (§3, lines ~64-67): "the hardening that unified role+epoch+blocklist on every write path — ADR-039 D1 (ADR-023/026: unified op-log epoch fence — derive role+epoch on every write path (A1+N1, HIGH) #157) — has shipped: `enforce_epoch_fence`/`enforce_epoch_fence_with_coll` is the single fence now called from both the hub write path and the mesh dialer relay." §4/§9 also correctly say "ADR-023/026: unified op-log epoch fence — derive role+epoch on every write path (A1+N1, HIGH) #157 (unified fence, closed — shipped)." The doc DOES still separately (and correctly) distinguish this from per-peer MESH enforcement, which is genuinely still future work tied to the P2P mesh initiative ([P2P epic] Phase 2 — daemon-as-peer mesh (dial + gossip + anti-entropy) #89) — that's a different, accurately-described gap, not stale text about ADR-023/026: unified op-log epoch fence — derive role+epoch on every write path (A1+N1, HIGH) #157.

Both fixes appear to have landed in an earlier pass without this issue being closed. Closing now with fresh verification.