ELAZAR DECISION: venus-state-backup gdrive leg ships ltm.md, the hub sqlite snapshot and .env.local unencrypted

Split out of VENUS-442 on coder-venus-cc's step-1 finding (tag coder-venus-cc-muwa5ymoe1sx), which falsified 442's premise rather than completing it. No value is disclosed here or on 442. MEASURED: the daily venus-state-backup bundle carries, unencrypted, the pg_dump passphrase in two places (~/.claude/ltm.md and the hub v2.sqlite snapshot) AND venus/.env.local with the live DSN and service-role key. 14 bundles kept on gdrive, 30 in the whey USB outbox. Consequence: a gdrive compromise yields live production database access regardless of what is done to the dump's gpg layer or to vault.secrets filtering inside the dump. The dump-side hardening VENUS-442 proposed would have had approximately zero confidentiality effect against this path while costing real recoverability. WHY THIS IS ELAZAR'S AND NOT A LANE'S: the unencrypted state bundle is his explicit 2026-06-14 no-encryption GO. Changing it reverses his own ruling on his own backups, and the fleet no-rotation rule is absolute - NOTHING here is rotated by any agent under any circumstance, and this row does not propose rotation. It proposes a storage-shape decision, which is his. THE DECISION, three options, no agent action until he picks: (a) accept as-is - the gdrive trust model stays his accepted risk, nothing changes, and this row closes as recorded-and-accepted; (b) encrypt the gdrive leg of the bundle; (c) keep the bundle unencrypted but drop ltm.md, the hub snapshot and .env.local from the GDRIVE leg only, retaining them on the USB outbox - this preserves recoverability on the medium he physically holds and removes the three high-value files from the cloud copy. My recommendation is (c): it changes one path rather than adding a key to manage, and it is the only option that reduces exposure without introducing a new way to lose access to a backup. Note for whoever implements whichever he picks: the recoverability argument is real and cuts the other way too - a bundle you cannot open is not a backup. Verify a restore from the post-change bundle before the old ones age out of the 14-day window.