perf(unbounded-consumption): short-circuit once length proves a block

[aymandakirgh]

Why

scanUnboundedConsumption runs on RAW (untruncated) input by design — the orchestrator passes raw input here (src/aegis-guard.ts:217) so the oversized-payload signal isn't hidden by maxInputLength truncation. But when input.length > maxLength (already a block, score 90), the detector still did full O(n) work over the entire body:

• longestCharRun(input) — walks every character
• maxTokenCount(input) — builds a Map over every whitespace-delimited token (and the split array)
• the UNBOUNDED_REQUEST regex over the full raw input

On a multi-MB body that's hundreds of ms of synchronous, event-loop-blocking CPU for zero extra detection benefit — the verdict is already "block". Measured on main:

• ~7MB input of 1M distinct tokens → ~190ms
• ~10MB single-char input → ~113ms

What

After the cheap input.length > maxLength check trips, return immediately with score: 90 and the length signal, skipping the char/token/regex scans. The block verdict and score are unchanged, so detection semantics are identical; only the worst-case per-request work is now bounded. Inputs within maxLength (≤ maxLength chars) still get the full char-run / token-repeat / unbounded-request analysis.

One detail-only change: an oversized input that also had e.g. a char-run previously listed both signals in details; it now lists just length=.... The safe/score/threatType are identical and no test asserted on the combined string.

Verification

• npm run typecheck — clean
• npm run lint — clean
• npm test — 314 passed / 1 skipped (added 5 regression tests in tests/unbounded-consumption.test.ts, incl. a <50ms bound on a 1M-distinct-token body)
• Probe (node/tsx) before vs after:
  • 1M-distinct-token (~7.9MB): 188ms → ~0ms, still {safe:false, score:90}
  • 10MB single char: 113ms → ~0ms, still {safe:false, score:90}
  • within-limit char-run / token-repeat / unbounded-request / benign: unchanged

🤖 Generated with Claude Code