Fix sanitizer base64 scan ReDoS

[cursor]

Bug and impact

A recent sanitizer change introduced a variable-length lookahead in ENCODING_BASE64. Benign long alphabetic inputs such as a 50k-character Z...Z string caused scan_encoding_blocks() to spend ~8.6s rescanning the same run, which can stall classify()/inspect() on user-supplied content and create a practical denial-of-service path.

Root cause

(?=[A-Za-z0-9+/]*[+/=]) was evaluated at each candidate position in long base64-like runs that ultimately contained no marker character, producing quadratic behavior before the scanner could reject the input.

Fix

Replaced the variable-length lookahead with a linear candidate regex and an explicit marker check (+, /, or padding) before recording base64 findings. Added regression coverage for long benign alphabetic runs and preserved padded base64 detection.

Validation

• PYTHONPATH=src python3 -m pytest tests/test_security_regressions.py::test_scan_encoding_blocks_long_alpha_run_completes_quickly tests/test_security_regressions.py::test_scan_encoding_blocks_still_flags_padded_base64 -q -> 2 passed
• PYTHONPATH=src python3 -m pytest tests/test_security_regressions.py tests/test_sanitize_encoding_evasion.py tests/test_sanitize_fragmentation.py -q -> 87 passed
• Timing check: scan_encoding_blocks('Z' * 50000) ~0.0005s; classify('Z' * 50000) ~0.52s
• Full suite: 282 passed / 3 skipped / 3 failed on known baseline vendored contract hash mismatches in tests/test_contract_document_hash.py