dweb: adopt the read-through sharing invariant (observer model) before data-bearing mesh surfaces land

The invariant

Sharing a thing must never grant a recipient access to data they couldn't already read directly.

This is the core of Cloudflare OS's "observer" system (docs/observers.md in github.com/cloudflare/cloudflare-os), which is itself the Sandstorm information-flow lesson made practical. Their decomposition:

1. Verify at attach. When Bob is granted access to a shared Gadget, each resource broker (Gatekeeper) verifies — against the vendor's own ACL, using a verifier minted by Bob's own account — that Bob could independently read everything the Gadget has ever ingested through it. Failure denies the share.
2. Forward exclusion. After Bob is attached, any new read that Bob couldn't make directly is blocked (or explicitly excluded from him), rather than silently widening what the share leaks.
3. Blunt stopgap first. Before the fine-grained system existed they shipped prohibitAllSharing: one maximally-sensitive observation ⇒ the thing can't be shared with anyone at all. All-or-nothing, but sound.
4. Re-verification runs at every open (lazy, catches upstream revocation), and authorization keys off the durable sharing graph, never off live sessions.

Why peerd doesn't have this hole today

peerd shares code (signed bundles) and rooms (consent-gated overlays), never live instances; a running dwapp has no local storage at all (opaque origin); room data is knowingly public-to-room per the join consent dialog. So there is currently no surface where sharing transitively leaks third-party-readable data.

Why it's about to matter

Roadmap items that create exactly this surface:

• Phase 2 content put/get — dwapps storing and serving content over the mesh. The moment a dwapp can serve bytes it read locally, "who may fetch this?" needs an answer better than "anyone in the room."
• A2A standing conversations (#35 is the inbound half) — the dweb actor relaying data to peers on request. Outbound ask/send is per-target consented today, but consent names a peer, not the data; once the actor has memory/session/skill context, a peer's question can pull data the peer couldn't read.
• Dwapp actors (#235) — an agent driving a dwapp composes both of the above.

Ask (deliberately modest)

1. Name the invariant in docs/security/THREAT-MODEL.md now (an INV-nn): no mesh surface may relay data to a peer unless (a) the peer could read it independently, or (b) the user explicitly consented to disclosing that data to that peer. Cheap to write down, expensive to retrofit.
2. Ship the blunt stopgap with the first data-bearing surface: a per-item "sharable / not sharable" bit checked at the serve boundary (peerd's equivalent of prohibitAllSharing), before any fine-grained system exists.
3. Design the fine-grained version later, borrowing the decomposition: verify-at-attach + forward-blocking, keyed off durable grant state, lazily re-checked. In a P2P setting the "vendor ACL oracle" is usually absent, so expect most classifications to be Cloudflare OS's strategy A (private-only) or D (low-stakes/public) rather than B/C (oracle-checked) — which is fine; the taxonomy is the useful part.

Start with docs/security/THREAT-MODEL.md and the referenced docs/observers.md. Record the proposed read-through sharing invariant as an INV-nn, then trace the first data-bearing mesh surface to define where the per-item sharing check belongs. Done means the invariant is documented and the initial stopgap and later verification design are scoped without silently widening data access.