long-lived cc session authenticates with a pre-rotation telemetry credential and spools silently
A cc session exports its .llmmsg-env credentials ONCE at launch. When a per-agent telemetry DSN is re-provisioned, the new value lands on disk and every systemd unit picks it up on its next start (EnvironmentFile is re-read per start), while any cc session started before the rotation keeps authenticating with the dead value. MEASURED ON VENUS 2026-09-12: my session env's BIN_VENUS_CC_TELEMETRY_DSN password and the one in ~/.local/bin/.llmmsg-env hashed differently. The on-disk value authenticated; my in-session one returned FATAL password authentication failed for user bin_venus_cc. The same in-session value had worked from this session roughly an hour earlier, so it was rotated underneath a live process. Compared by sha256 of urlparse(dsn).password, first 12 hex, never by printing either value. WHY IT IS SILENT, WHICH IS THE ACTUAL DEFECT: metrics_write() returns 0 unconditionally - on insert failure it spools the row to JSONL and reports success, by design, so telemetry never fails its caller. A dead credential therefore produces no error, no log line and no non-zero exit. It produces a growing spool file. The instrument is doing exactly what it was built to do, and that is why nobody notices. Net effect is delayed telemetry, not lost telemetry. BLAST RADIUS IS VENUS-SIDE ONLY - bin-whey-cc measured whey and it is NOT affected: whey's launcher does not export the telemetry DSN into agent sessions at all, scripts source ~/.config/telemetry.env per invocation so there is no long-lived in-memory copy, whey authenticates as telemetry_whey_rw (a different credential from the one that moved), its telemetry.env mtime is 2026-09-03, and its spool is three zero-byte files with July mtimes. Do not send anyone to whey to restart sessions. CURE is a session restart, not an edit - re-exporting by hand fixes one variable and leaves the rest of the overlay stale. Restarting another agent's session is default DENY per agent-launch-permission.md, so this row is a record and a detector request, not a work order to restart anything. CHEAPEST DETECTOR, per pmmaster: announce a per-agent DSN rotation on aro:nw at the time it happens. The failure is silent by construction, so knowing a rotation occurred is the only low-cost signal. A second option is a startup self-check comparing the in-session DSN hash against the on-disk overlay. Filed by bin-venus-cc because I hold the measurement; pmmaster-evolutiva-cc asked for the row and ruled it does not warrant a fleet broadcast.