Idea: let the SDK say which telemetry got lost, and where

[4ktLuffy]

Right now it's hard to tell "no errors" from "errors that never arrived". Client reports only cover drops the SDK knows about, and a few bugs I ran into recently were silent:

• spans lost when a Node process exits on its own (Span streaming (default in v11) loses all buffered spans when the Node process exits on its own #25531, fixed in fix(node): Flush buffered streamed spans on process exit #25539)
• one NaN attribute dropping a whole batch of logs/spans in Python (One NaN or inf value silently drops the whole batch of logs, spans or metrics sentry-python#8066, fixed)
• traces dropped as missing_dsc while the SDK gets a 200 (Span streaming drops continued traces without baggage: empty frozen DSC leads to missing_dsc (breaks Uptime check traces) #25243)

This seems related to getsentry/sentry#122954 and to questions like #7276.

Idea: the SDK keeps a small audit of what it committed to send, sent on its own path so it can't fail together with the data. Each envelope lists what's in it, and Relay records what it drops and why. Sentry can then say per release: delivered, dropped on purpose (sampling, quota), lost (with the hop and reason), or unknown.

I built a local prototype on @sentry/node and a patched Relay to check if it's worth it:

• Demo: a release "looks better" (slow checkouts 1 -> 0), but one NaN silently dropped 313 spans, 37% of the checkout route. The ledger flags the comparison as unreliable, and reports "delivered" again after the fix.
• 26 loss scenarios: no false "delivered", no wrong items reported. Today's client reports showed nothing in 13 of the 20 cases where data was really lost.
• Cost on a realistic Express app: about 0% CPU at 10% sampling, 4-7% at 100%. Under 0.4% extra upload size.

It's Node only and doesn't cover logs, metrics or sessions yet.

Would this direction be useful? Happy to share the code or write it up as an RFC.