Telemetry delivery-health signal (friction-write swallow)

log-action-error.ts:41 discards both async rejection and sync throw on friction telemetry writes — a dropped write and a friction-free week both read as zero rows, so every downstream instrument (vUserFrictionEvents, weekly UX-pain digest, admin/friction) inherits an unverifiable zero. The swallow is deliberate/correct (telemetry must never break the user path); ask is observability of the failure, not propagation. Required: durable queryable delivery-health signal or bounded-retry outbox carrying class/route/action+reason (NOT raw user text), admin count+age surface, UX action still succeeds when logging fails. Open design Qs for PM/room to settle before implementation: (1) client-side loss vs server-side write failure are different problems — cover one/both/declare boundary; emailOutbox precedent is server-side only, can't observe a request that never arrived. (2) health signal in appEvents is self-referential — a write failure can't log itself to the table that failed. (3) client retry risks duplicate friction rows, needs a dedup key. Class-A.