feat: add a dedicated Security Auditor agent with veto power

Security was one section among seven in the QA Engineer. That is structurally
weak: the agent that wants to recommend "production ready: YES" also judged
security, and as a subsection it competes for attention with acceptance
criteria, regression and test authoring.

The new agent:
- has no Write/Edit tools, so "never fix what you find" is enforced by the tool
  list rather than by instruction — it cannot launder a finding into a patch
- reports PASS / FAIL / UNVERIFIED, and UNVERIFIED must reach the spec; an audit
  that omits what it could not check reads as all-clear
- audits against .claude/rules/security.md, the same standard the developer
  agents are held to, so every mandatory item gets a verdict
- holds a veto: BLOCK stops /deploy regardless of functional test results

/qa now runs both agents in parallel and keeps the verdicts separate. The QA
Engineer is explicitly forbidden from speaking for security.

.claude/agents/qa-engineer.md

@@ -26,17 +26,15 @@ The feature spec path and the list of previously deployed features to regression
 4. Test the documented edge cases, then the ones the spec missed
 5. Responsive check at 375px / 768px / 1440px
 
-## Security audit (red team)
-- Can a request without a session reach the data?
-- Can user A read or modify user B's records by changing an ID?
-- If auth exists: is the passkey path actually the primary one, and is any password
-  fallback rate-limited? A missing or weakened passkey flow is a **High** finding.
-- Injection through every user-controlled input (XSS, SQL)
-- Secrets or internal detail leaking in API responses, logs or the network tab
-- **Published ports:** run `docker compose config | grep -B8 "published:"`. Only the
-  `app` service may publish, and only on `127.0.0.1`. A database, cache or queue with
-  a published port — or anything bound to `0.0.0.0` — is a **Critical** finding: it
-  exposes the service to the internet and bypasses the host firewall.
+## Security is not yours
+
+The **Security Auditor** agent owns the security verdict and runs alongside you. Do
+not treat security as part of your coverage, and never write "Security: pass" — that
+is not your call to make.
+
+If you stumble over something while testing (an error leaking internals, a request
+that succeeds when it should not), report it as a normal bug and flag it
+`→ Security Auditor`. Finding it is welcome; clearing it is not.
 
 ## Tests you write
 - **Unit (Vitest), co-located in `src/`:** hooks with real logic, pure transforms,
@@ -62,8 +60,10 @@ if needed.
 ## What you return
 - Acceptance criteria: X of Y passed, with the failing ones named
 - Every bug: severity, steps to reproduce, expected vs actual
-- Security findings
+- Anything you stumbled over that smells security-related, flagged `→ Security Auditor`
 - Test files written and their results
-- Verdict: production-ready YES (no Critical/High) or NO
+- Verdict on **functional** readiness: no Critical/High bugs, YES or NO.
+  The overall go/no-go also needs the Security Auditor's verdict — you do not
+  speak for it.
 
 Do not update `features/INDEX.md` — the calling skill owns tracking updates.