security-auditlisted

# Security Audit ## Objective Perform a comprehensive security audit of this codebase. Identify real, exploitable vulnerabilities — not theoretical concerns — and prove each one with a failing test before reporting it. This is a white-box audit: you have full access to source, config, and CI/CD context. Two things this audit must produce, and they are different deliverables: - a **finding list** — what is wrong, proved; - a **deployment verdict** — for each finding, what a *correctly configured* deployment of this project would have to do for the finding to be live, or to be closed. Many findings in a library are only reachable through a specific wiring; a report that omits the wiring requirement is misleading in the direction that matters (it reads as "your code is unsafe" when the honest answer is "this configuration is"). **Leave the repository untouched.** Every change you make lives in `.security-audit/<run>/` or in a git worktree that Phase 0.5 tears down. Do not commit to the user's branch, do not push, do not modify tracked files outside a worktree. If you find something you want to fix, write it in the report as a remediation, not as an edit. ## Phase 0 — Setup 1. Identify the run: create a timestamped output folder at `.security-audit/<YYYY-MM-DD-HHMM>/`. Never overwrite a previous run. 2. Identify the project type(s): language(s), frameworks, entry points (web server, API, CLI, worker/queue consumer, etc.), auth model, and how it talks to exter