Capture buffer stores credentials the filter cannot anchor on - two real instances in one project

[jsirish]

hooks/_lib.sh:455-461 documents the gap honestly: a credential attached to a bare single-letter CLI
flag (mysql -p<password>, curl -u user:pass) has no keyword to anchor on, and -u/-p are too
overloaded to redact generically.

That known gap has now produced two real captures in a single project's buffers:

1. A production database password, inline in repeated ssh ... mysql -h... -u... -p<password>
   command records.
2. A third-party API key, in a git grep command whose search pattern was the key itself. The
   well-known-prefix rules at :493-498 cover ghp_, xox*, sk- and AKIA; this vendor's prefix
   is not in that set.

Neither was caught by the filter. One was found and scrubbed by hand a session later; the other was
still sitting there four sessions on. Buffers are local-only and gitignored, so this is not a
disclosure — but it makes the buffer a credential store that nobody treats like one, and every
subagent that reads a buffer reads those too.

Two targeted mitigations, both narrower than the generic rule the comment rightly rejects:

• Anchor on the command, not the flag. -p is only unambiguous after a known client name.
  Matching \b(mysql|mysqldump|mariadb)\b[^|;]*\s-p\S+ covers the realistic case without touching
  ssh -p 22 or docker run -u.
• Extend the prefix list. It is a maintained allowlist already; adding a handful of current
  vendor prefixes is cheap and has near-zero false-positive cost.

Optionally: have handoff's existing re-scan report what it masked, so a leak that predates a rule
gets noticed rather than silently persisting.