perf: avoid repeated hash scans for candidates on the same line

[svozza]

Secret scanning searched each full line for hash and UUID containers again for every candidate on that line. Large generated JSON lines made this expensive.

Compute those containers lazily once per line. Keep the existing detectors, suppression rules, candidate order, placeholders and redaction behavior. Add regression tests for repeated candidates, independence between lines and lines without candidates.

Full Grafana preparation fell from 431.67s to 183.42s in the local comparison. One 402,894-character JSON fixture fell from 139.71s to 1.04s and returned the same 94 candidates.

Validation:

• All six frozen source comparisons produced identical prepared prompts, ordered runtime secrets, policy and redacted source trees. Other cases showed only small timing differences.
• 2,379 unique deterministic tests passed across the full suite and targeted runs; two fixture-dependent tests skipped. Four sandbox-blocked loopback tests passed when rerun with socket access.
• Type checking and diff checks passed.

These are preparation measurements, not model accuracy or end-to-end review measurements. The initial Grafana pair overlapped on four CPUs; the other pairs ran sequentially in alternating order.

CI passed on the tested commit: 2,379 deterministic tests, type checking, all 42 review scenarios and all six planning scenarios. The first evaluation attempt had one invalid sample after the provider safety classifier interrupted a response. The unchanged rerun passed; the failed scenario’s prepared inputs were confirmed identical to main.