VENUS-367 — telemetry delivery-health: failed friction writes are indistinguishable from zero friction

Root WI raised by audit-venus-ca (msj2d8yd4706), spec supplied by them on request (msj2f67mxcs3). NOT a patch to VENUS-365 — that incident logged correctly and is closed. PROBLEM. Client feedback telemetry is fire-and-forget by design. src/lib/log-action-error.ts:41 does `void recordActionErrorToast(...).catch(() => {})` inside an outer `try {} catch {}`, so BOTH the async rejection and any sync throw are discarded. logger-core logEvent does not surface delivery failure either. Consequence: a dropped friction write and a genuinely friction-free week produce the SAME reading — zero rows. Every instrument built on that plane (vUserFrictionEvents, the weekly UX-pain digest, admin/friction) inherits an uncontrolled zero it cannot detect. Same class as the standing rule: prove the instrument CAN return non-empty before trusting its zero. NOT A DEFECT ON ITS OWN. The swallow is deliberate — telemetry must never break the user path. The ask is observability of the failure, not propagation of it. REQUIRED BEHAVIOUR (audit spec, verbatim intent): - Failed feedback writes increment a durable, queryable delivery-health signal, OR enqueue to a durable outbox with bounded retry. - The record carries event class / route / action and a failure reason — NOT raw user text. - An admin surface exposes a health count + age, so silent telemetry loss is distinguishable from zero friction. - The UX action stays successful even when logging fails. Non-negotiable; do not regress this while fixing it. PRECEDENT IN-TREE: `emailOutbox` is the only existing outbox table (drained by src/app/api/cron/drain-email-outbox/route.ts). Same shape is a candidate, but note the asymmetry — an email outbox is written SERVER-side where a durable write is available. The failing case here is often the CLIENT losing the network, where there is no server to enqueue to; a server-side outbox cannot observe a request that never arrived. Design must state which failure modes it actually covers rather than implying all of them. OPEN DESIGN QUESTIONS for pm-venus-cc: 1. Client-side loss vs server-side write failure are DIFFERENT problems with different remedies. Cover one, both, or declare the boundary? 2. Does the health signal live in appEvents (self-referential — a failure to write cannot log its own failure to the same table) or a separate counter? 3. Bounded retry on the client risks duplicate friction rows; dedup key needed. Class-A (touches the logging plane every server action depends on). Coordinate with pm-venus-cc before implementing.