venus-db-backup.sh: trash||rm precedence hard-deletes clinical dumps when trash exists and FAILS

venus-db-backup.sh prune() line: 'command -v trash >/dev/null && trash "$f" 2>/dev/null || rm -f "$f"'. Shell && || precedence makes this NOT the intended if/else. It reads as (command -v trash && trash f) || rm -f f, so rm -f fires in TWO cases, not one: (i) trash is absent - intended fallback; (ii) trash EXISTS and FAILS - unintended HARD DELETE. Case (ii) is the dangerous one because it triggers exactly when trash is broken, full, or the target is on a filesystem trash cannot handle - i.e. precisely when a human would want the file kept and recoverable. Violates the fleet rule 'File operations: trash command (never rm/hard delete)' while appearing to honor it, which is why it survived review. The artifacts are complete logical dumps of a live clinical database, so a silent hard delete is unrecoverable data loss with no trace. FIX: real if/else - if command -v trash; then trash "$f" || log-and-skip; else rm -f "$f"; fi - and decide explicitly whether a trash failure should abort the prune rather than escalate to rm. MUST-FAIL FIXTURE REQUIRED: a stub 'trash' on PATH that exits 1 must NOT result in the file being removed; the current code deletes it. Same class as mem:reference-gates-need-a-must-fail-fixture. Blocked while venus-db-backup.sh is evidence in the live VENUS-350 P0. Sibling of VENUS-358 (same function, one push once unblocked).