fix(web): Hotfix #11 — CodeQL #36 js/regex/missing-regexp-anchor in multi-page-flows test

CodeQL alert #36 (severity: HIGH, rule: js/regex/missing-regexp-anchor)
fired on commit a9e229b:

  web/src/__tests__/multi-page-flows.test.tsx:161
    Missing regular expression anchor
    When this is used as a regular expression on a URL, it may
    match anywhere, and arbitrary hosts may come before or after it.

Root cause:
  Phase 8's TEST-M1 multi-page-flow test verifies the
  CertificateDetailPage surfaces the same common_name the list row
  showed. The original assertion used a case-insensitive regex
  matcher:

    screen.getAllByText(/api\.example\.com/i)

  CodeQL's heuristic flagged this as URL-shaped (literal-dot
  pattern with TLD structure) and missing `^`/`$` anchors. The
  rule exists because unanchored URL regexes are dangerous in
  security contexts (host-allowlist sanitizers). This is a test
  file matching DOM text content — not URL sanitization — so the
  alert is technically a false positive in semantic terms.

  But CodeQL is correct that the pattern READS as a URL regex,
  and a future engineer copy-pasting this matcher into actual
  validation code would inherit the vuln. Best to remove the
  unanchored-regex pattern from the codebase at the source.

Fix:
  Switch from a regex matcher to testing-library's function
  matcher with a plain-string `.includes()`. Same case-insensitive
  substring semantics, zero regex for CodeQL to flag:

    screen.getAllByText((content) =>
      content.toLowerCase().includes('api.example.com'),
    )

  The function form is also more accurate for what the test
  actually checks: the detail page may render the cn inside a
  labelled cell ("Common name: api.example.com"), so substring
  match is the intended semantic. Comment block above the
  assertion documents the rationale so a future refactor doesn't
  re-introduce a URL-shaped regex.

  Other unanchored regexes elsewhere in the test suite
  (`screen.getByText(/UTC/)`, `/2026/`, `/Enabled/`, etc.) do
  NOT pattern-match as URL-shaped and have passed prior CodeQL
  scans — not touching them. Over-reach has its own cost.

Verification:
  • npx tsc --noEmit — exit 0
  • npx vitest run src/__tests__/multi-page-flows.test.tsx — 3/3 pass
  • npx vite build — ✓ built in 3.31s
  • All 48 CI guards pass
  • origin/master ground-truthed via GitHub API (4909691) BEFORE
    commit per the operating rule

Falsifiable proof: CodeQL re-scan on push should auto-close #36
(rule no longer has a matching pattern at multi-page-flows.test.tsx:161).

web/src/__tests__/multi-page-flows.test.tsx

@@ -157,8 +157,18 @@ describe('Multi-page Vitest flows — Phase 8 TEST-M1', () => {
       });
 
       // 4. Detail page surfaces the same common_name the list showed.
+      // Function matcher (NOT regex) — closes CodeQL alert #36
+      // (js/regex/missing-regexp-anchor). Same case-insensitive
+      // substring semantics as the original /api\.example\.com/i but
+      // no regex for CodeQL to flag. Function form also tolerates the
+      // detail page rendering the cn inside a labelled cell ("Common
+      // name: api.example.com") where exact-match string would fail.
       await waitFor(() => {
-        expect(screen.getAllByText(/api\.example\.com/i).length).toBeGreaterThan(0);
+        expect(
+          screen.getAllByText((content) =>
+            content.toLowerCase().includes('api.example.com'),
+          ).length,
+        ).toBeGreaterThan(0);
       });
     });