[diegosouzapw]

Closes #13907

Root cause

tests/unit/correctness/sanitizers.property.test.ts asserted an absolute 250ms
wall-clock ceiling for sanitizeErrorMessage() on adversarial inputs (1,000–20,000
chars). That ceiling had no margin over the sanitizer's real fixed cost: the input is
truncated to MAX_ERROR_LEN + MAX_ERROR_SCAN_HEADROOM (4096 + 512 = 4608 chars), then
run through 3x redactSensitiveErrorText(redactErrorPaths(stripStackTail(...)))
interleaved with 2x normalizeSecurityEscapes (open-sse/utils/errorSanitization.ts:696-705,
added by #12506). That layered pipeline's fixed per-call cost is what the assertion was
timing, not backtracking — there is no catastrophic backtracking here, so the test failed
on ordinary CI/machine load rather than on any real ReDoS regression.

Fix

Replaced the fixed-ms assertion with a check on the actual security property: the
sanitizer's cost must not scale with adversarial input size beyond a generous
noise-tolerant allowance (baseline is a median of small-input runs; the allowance is
baseline * 100 + 1000ms), plus a coarse 5s absolute "did it hang forever" backstop kept
only as a secondary check. A real superlinear/exponential ReDoS blows past this by orders
of magnitude regardless of machine load; ordinary fixed-cost regex work never gets close.
No production code was touched — this is a test-only fix per the plan's recommended
Option A. Option B (optimizing the sanitizer's fixed pipeline cost) is explicitly
deferred as a separate, security-boundary-sensitive change.

Regression test — RED → GREEN

tests/unit/correctness/sanitizers.property.test.ts

• RED (unfixed code, this worktree before the edit): too slow: 317.066339ms for len=1000
  (also reproduced pre-existing at 440-643ms in the triage plan-file's own probe run).
• GREEN (after the edit), confirmed stable across 4 consecutive runs on a heavily loaded
  box (load average ~72 from many parallel CI/agent processes during validation):

  ✔ sanitizeErrorMessage never leaks a file path / stack frame
  ✔ sanitizeErrorMessage cost does not scale with adversarial input size (ReDoS guard)
  

Gates run

• node scripts/check/check-file-size.mjs — no violation on the touched file (one
  pre-existing, unrelated violation on tests/unit/chatcore-translation-paths.test.ts,
  not touched by this PR).
• node scripts/check/check-complexity.mjs — OK (2857 violations vs baseline 3218).
• node scripts/check/check-cognitive-complexity.mjs — OK (1291 violations vs baseline 1437).
• npm run typecheck:core — exit 0.
• npx eslint --suppressions-location config/quality/eslint-suppressions.json tests/unit/correctness/sanitizers.property.test.ts — clean.
• node --import tsx/esm --test tests/unit/correctness/sanitizers.property.test.ts — green,
  run 4 times to confirm stability under load.
• node scripts/check/check-changelog-integrity.mjs — OK.

Base-red

⚠️ base-red inherited: #14004 — docs env/docs contract (fixed separately in #14022), chatHelpers file-size drift

Scope

Test-only change (tests/unit/correctness/sanitizers.property.test.ts) plus a changelog
fragment. No production code touched.

[diegosouzapw]

Validated in local merge-train /tmp/mt-train3b.log on 192.168.0.113 @ train tip 408e2128791696a18966681953136fc96aeb99b0 (32 PRs boarded): static gates green; full test:unit 40694 tests, 17 failing — every one reproduces on the pure release tip (base-red sweep list), zero new reds. Merged --admin per merge-gates §4/§7.