Consolidate Evolutiva backups into one performed/monitored/inventoried lane

ELAZAR DIRECTIVE 2026-08-07 out of VENUS-350. Backups are sprawled across at least 4 uncoordinated lanes with no common registry, no reliable log, and no inventory. Consolidate to ONE place where backups are performed, monitored and inventoried. MEASURED SPRAWL (verified today, not recalled): (a) whey /opt/evolutiva-backups/run.sh v2.2.3, systemd evolutiva-backup@{venus,mars,pluto}.timer. pg_dump --schema=public --schema=auth, DIRECT connection. 3/day since 2026-06-11; every 30min before that. Excludes table DATA for notifications + auth.flow_state/sessions/refresh_tokens. NOT a git repo, no changelog, no version history - the only provenance is a single mtime plus a self-asserted comment. (b) venus venus-db-backup.sh via sh.git, venus-db-backup.timer every 2h, full dump, env DSN. (c) A DEAD gdrive lane, ~406 venus runs, artifacts already destroyed by its own retention. Stopped 2026-06-16. (d) mars/db/backup-db.sh - manual only, --schema=public --schema=auth, NO EXPECTED_REF GUARD (terra has one). If .env.local is absent it falls through to an already-exported DATABASE_URL_DIRECT, i.e. it can dump the WRONG PROJECT. venus has no db/backup-db.sh at all. DEFECTS THAT MADE VENUS-350 EXPENSIVE - each is a requirement for the replacement: 1. backup-log.sqlite is UNRELIABLE IN BOTH DIRECTIONS, proven on a directly-verifiable 4-day window: orphan start rows with no artifact, AND a missed completion (id 6210) that DID produce a valid artifact on disk. A backup log that can silently miss a completed run is worse than none, because it is trusted. 2. USB destination uses DAY-ONLY filenames, so same-day reruns OVERWRITE each other. The USB count is a floor on days-with-a-surviving-dump, NOT a run count - it cannot answer how many times a backup ran, which is exactly what we needed. 3. No inventory anywhere maps lane -> schedule -> destination -> retention -> owner. Reconstructing it took five agents a full day. 4. Retention destroys the evidence needed to audit the lane itself (the dead gdrive lane is permanently unmeasurable for this reason). 5. Provenance is self-asserted: run.sh comments cite an APPROVAL date, and no git history exists anywhere to check what actually changed when. REQUIREMENTS FOR THE CONSOLIDATED LANE: - One inventory: every lane with schedule, connection path, scope flags, destination, retention, owner. Registered with pm-llmmsgsrv-cc (maintainer registry), not only in a repo doc. - Artifact filenames carry FULL TIMESTAMP, never day-only. - Run records reconcilable AGAINST THE ARTIFACTS, artifact wins on conflict - declared config lost to the artifact 4/4 times on VENUS-350. - Version-controlled scripts. run.sh living outside git is why the exclude-flag deploy date was unanswerable from the filesystem. - Every lane identifies itself per-principal once the credentials directive lands, so a dump is attributable at the DB. CONTEXT: Supabase platform gives ZERO restorable backups on venus (API: pitr_enabled false, backups []). Our own dumps are the ONLY restore path. This is not housekeeping. DEPENDENCIES: pairs with the fleet credentials/logging directive routed to pmmaster-evolutiva-cc (per-script + per-agent DB users, disable 0.0.0.0/0, enable log_connections). Logging should land FIRST - additive, breaks nothing, makes everything else verifiable. Do NOT start with CIDR tightening: it can cut off the backup lane, all local tooling and possibly Vercel runtime in one edit, and it fails closed silently. Venus is LIVE with real clinical data. No rotation of existing credentials as a side effect (Section No-Rotation) - issuing NEW per-principal credentials is not rotation.