Add view event bindings for default nostr client

docs/moderation/README.md

@@ -17,6 +17,9 @@ bitvid is follow-centric. Your Home feed comes from people you follow (F1). Disc
 - **Lists**: NIP-51 (mute list 10000, categorized people 30000, bookmarks 30001).
 - **Replies/threads**: NIP-10 (comments).
 - **Counts**: NIP-45 (relay COUNT; optional fallbacks).
+- **View metrics**: [`js/nostr/viewEventBindings.js`](../../js/nostr/viewEventBindings.js) wraps the shared client so moderation
+  toggles hit the same record/list/subscribe/count helpers that enforce our NIP-71/NIP-78 guard rails when relays disable optional
+  methods.
 
 ## Runtime flow (blur, hide, override)
 - [`ModerationService`](../../js/services/moderationService.js) orchestrates ingest and scoring. Review the service for the trusted-report math and helper entry points.

docs/nostr-analytics.md

@@ -24,6 +24,10 @@ To avoid double-counting the same session, the playback stack respects the coold
 
 Every view event includes a unique `#d` tag derived from the pointer scope, the signing actor, and high-entropy randomness. Because kind `30079` is parameterized, this `#d` tag is what keeps individual view notes permanent—without it, a fresh event would overwrite the previous one from the same actor. Leave the tag intact (or provide one when overriding the schema) so relays retain the full stream of view history.
 
+### Client bindings & feature toggles
+
+When wiring moderation or playback toggles into view analytics, call through [`js/nostr/viewEventBindings.js`](../js/nostr/viewEventBindings.js). The binding wraps the singleton client so feature flags, relay discovery, and COUNT/LIST fallbacks all run through the same guard clauses that enforce the NIP-71/NIP-78 schemas. Modules that need to no-op when relays disable optional methods can rely on the binding’s "unavailable" errors to short-circuit cleanly.
+
 ### Hydration, COUNT, and UI sync
 
 Background hydration keeps optimistic counts honest. The view counter subscribes to live events while simultaneously fetching historical lists and issuing a `COUNT` request. Whenever the authoritative total returned by `COUNT` exceeds the locally accumulated sum, the hydration routine overwrites the optimistic value so the UI stays aligned with relay truth. If `COUNT` falls back (because relays reject it or the browser is offline), the locally deduped history still anchors totals, and the next successful hydration pass reconciles any drift. This interplay means cards, modals, and dashboards settle on the same number without requiring a full page reload.