Context-cued bare SSNs evade both the redactor and adapter SSN detectors

Both SSN detectors — `credential_redactor.py` ("US SSN", merged in #3531) and the adapter-side `PII_PATTERNS` entry (aligned in #3591) — require a separator between digit groups. That correctly stops bare nine-digit numbers (tracking/ABA/invoice numbers) from hard-blocking, but it also means an SSN written bare next to an explicit cue passes both gates:

- `SSN: 745102386`
- `ssn=745102386`
- `social security number 745102386`

None of these match at either detector today (verified against both patterns), so tool output carrying a cued bare SSN is neither redacted at the gateway nor blocked by the adapters.

Suggested fix: add a context-cued branch to the shared pattern — a case-insensitive cue (`ssn`, `social security`) within a short window before an undelimited nine-digit run — applied identically in both files so the detectors stay in lockstep (divergence between them was nearly reintroduced twice; #3591 restored parity). Regression tests should pin the cued-bare forms as matches while keeping the bare-uncued FP corpus (from #3531/#3591) as non-matches.

Related: the Rego policy templates under `examples/policy-templates/` deliberately keep the loose nine-digit form for detection-only scoring; if the cued branch lands, the templates could adopt it too.

Found while reviewing #3591; pre-existing on both sides, not introduced there.

Start with credential_redactor.py and the adapter-side PII_PATTERNS entry, comparing how the existing SSN patterns handle separators and the bare-number false-positive corpus from #3531/#3591. Add regression coverage for the three context-cued forms while preserving bare uncued numbers as non-matches, then verify both detectors remain identical; consider the Rego templates under examples/policy-templates/ separately.

Written by the indexing model from the issue text.