Fix quadratic base64 scan in SCP classifier

[cursor]

Bug and impact

A benign untrusted input such as "Z" * 32000 could make scp_utils.inspect() take multiple seconds due to quadratic base64 marker scanning. This path is used by scp_inspect, scp_validate_output, run_pipeline, and contribution anonymization, so inputs well below the configured 2M character cap could cause significant scanner/API latency or practical denial of service.

Root cause

ENCODING_BASE64 used a variable-length lookahead over [A-Za-z0-9+/]* to require a base64 marker. For long alphabetic runs with no marker, the regex rescanned the remainder of the string from many start positions.

Fix

Replaced the lookahead regex with a linear candidate regex and moved the marker check into Python after each match. Added a regression test covering long benign alphabetic input and preserved existing padded-base64 corpus behavior.

Validation

• PYTHONPATH=src python3 -m pytest -q tests/test_sanitize_encoding_evasion.py::TestBase64Chains::test_long_alpha_run_classifies_without_quadratic_base64_scan tests/test_corpus_wave3.py::test_wave3_inspect_tier -> 18 passed
• Original repro after fix: scp_utils.inspect("Z" * 32000) -> tier=clean, elapsed 0.3403s
• PYTHONPATH=src python3 -m pytest -q -> 281 passed, 3 skipped, 3 failed on known vendored contract hash mismatches (tests/test_contract_document_hash.py)
• git diff --check origin/main..HEAD -> clean