fix(code reviewer) error pattern precision

[St0rmz1]

Summary

The admin Error Analysis matched HTTP status codes as bare substrings, so
LIKE '%429%' bucketed any message containing those three digits as Rate
Limited. A session id, byte count, duration or timestamp was enough to trigger
it. '%500%' had the same problem and caught text like "5000 tokens".

This switches the status code branches to a Postgres word boundary regex, so
429 matches in "HTTP 429" but not in "4290", "14290" or "req_429abc".

The defect affected every status code branch, not just 429, so the fix covers
401, 403, 404, 429, 500, 502 and 503.

Changes

• Add httpStatus(code) and anyHttpStatus(...codes) helpers in
  buildErrorCategoryExpr, producing error_message ~ '\y<code>\y' in place of
  LIKE '%<code>%'.
• Apply them to the Rate Limited, Auth / Permission Error, Not Found and
  Upstream Server Error branches.
• Fold the duplicated case variants ('%rate limit%' OR '%Rate limit%') into
  ILIKE on the branches being rewritten.
• Add three tests: embedded digits are not treated as status codes, genuine
  status codes still bucket correctly, and rate limit text matches regardless of
  case.

Verification

No manual testing. This is a SQL classification change with no user facing entry
point to exercise by hand, and it is covered by tests against a real database.

• admin-code-reviews-router suite, 21 tests
• Mutation check: with the old LIKE '%<code>%' restored, the new precision
  test fails; with the fix in place all 21 pass. Confirms the test is not
  passing for an unrelated reason.

Visual Changes

N/A. No component or layout changes. Bucket counts on the admin Error Analysis
chart will shift for existing rows, but that needs production data to
screenshot.

Reviewer Notes

• The regex pattern is inlined rather than bound as a parameter. This expression
  is used in both SELECT and GROUP BY, and parameter placeholders are renumbered
  by position, so Postgres would stop recognizing the two as the same expression
  and the query would fail with a GROUP BY error. Same reason the reason labels
  directly above are inlined. The pattern is built from a number literal, so
  there is nothing to escape.
• Practical blast radius is mostly historical rows. Structured terminal_reason
  cases are matched first in the CASE, so rows that carry a mapped reason never
  reach these message patterns. The fallback applies to rows written before the
  callback started consuming failure.code.
• ILIKE is a small behavior change beyond precision. Those branches were case
  sensitive before, so "Authentication" or "RATE LIMIT" did not match and now
  do. That is the intent, but it is a recall change rather than a precision one.
• The timeout, parse and network branches still use case sensitive LIKE
  with duplicated variants. They are not part of this defect, so they were left
  alone.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

Reviewed the word-boundary regex refactor of buildErrorCategoryExpr and its new tests; the \y boundary logic, ILIKE case-insensitivity change, and inlined-literal rationale are all consistent with the stated intent and I found no correctness or security issues in the changed lines.

Files Reviewed (2 files)

• apps/web/src/routers/admin-code-reviews-router.ts
• apps/web/src/routers/admin-code-reviews-router.test.ts

---

_{Reviewed by claude-sonnet-5 · Input: 22 · Output: 5.7K · Cached: 407K}

_{Review guidance: REVIEW.md from base branch main}