venus-db-backup.sh: prune glob spans plaintext+encrypted lanes, sharing one KEEP budget

venus-db-backup.sh prune() glob 'venus-prod-*.sql.gz*' matches BOTH the legacy plaintext .sql.gz lane (dead lane, stopped 2026-06-16) and the current encrypted .sql.gz.gpg lane, so a single KEEP=84 budget is shared across two naming conventions. Measured 2026-08-07: dest ~/gdrive/backup/venus held exactly 84 files = 74 .gpg + 10 legacy plaintext, so effective ENCRYPTED retention is 74 (~6.2 days at 12 runs/day), not the 84/7-days the constant documents. Second, live consequence: because ls -1t is newest-first, the 10 oldest plaintext files occupied prune positions 75-84 and were being destroyed at 1 per run - all 10 gone by ~2026-08-08 04:00 UTC. Those artifacts are VENUS-350 evidence AND the last unencrypted clinical copies on a consumer cloud mount; nobody decided to delete them, a glob did. Evidence preserved 2026-08-07 08:32 UTC under pmmaster-evolutiva-cc authorization (msiorxd2q1mh) to ~/.local/state/venus-350-evidence/ (AES256, round-trip verified byte-identical, wrong-passphrase must-fail fixture passed) - that is preservation, NOT the fix. FIX: scope the glob per lane so each retention budget counts only its own artifacts, and make KEEP mean what the comment claims. Blocked while venus-db-backup.sh is evidence in the live P0; see mem:owned-scripts.