fix(rees): TypeError in safeCodeSpan -- non-string value reaches .replace() (13 Sentry events)

[JSONbored]

Summary

TypeError: value.replace is not a function in the REES enrichment service's Markdown rendering — a non-string value reaches a helper typed to accept only string.

Evidence (Sentry)

GITTENSORY-15 — 13 events, first seen 2026-07-02, last seen 2026-07-05. Full stack trace:

src/render-helpers.ts:29 (safeCodeSpan)
  return `\`${value.replace(CODE_SPAN_UNSAFE, (char) => CODE_SPAN_REPLACEMENTS[char] ?? "�")}\`";
src/analyzers/registry.ts:824 (ANALYZER_DESCRIPTORS.render)
  ...${helpers.safeCodeSpan(`${item.file}:${item.line}`)} — ${helpers.safeCodeSpan(item.term)} → ${helpers.safeCodeSpan(item.suggestion)}
src/render.ts:20 (renderDescriptorSection)
src/render.ts:479 (renderBrief)
src/brief.ts:429 (buildBrief)
src/server.ts:77

Request: POST https://enrichment.gittensory.aethereal.dev/v1/enrich.

Root cause — verify from the stack trace, not from Seer

Seer's summary for this issue ("Increase the transport headroom constant so analyzers stop early enough for the response to reach the client before its abort fires") is about a timeout/transport issue and does not match this stack trace at all, which is a plain TypeError from a .replace() call. Ignore Seer's summary for this issue; the stack trace is unambiguous.

At registry.ts:824, three safeCodeSpan(...) calls are made: one on a template-literal-interpolated string (${item.file}:${item.line}, already coerced to a string), and two on raw values (item.term, item.suggestion) with no coercion. If either of those is undefined, null, a number, or an array for some analyzer's finding shape, safeCodeSpan's .replace() call throws.

Requirements

1. Either make safeCodeSpan defensive (accept unknown, coerce via String(value) or similar, matching the codebase's usual defensive-formatting conventions) or ensure every call site only ever passes a genuine string — pick whichever matches this file's existing house style for similar helpers.
2. Identify which analyzer/finding shape can produce a non-string term or suggestion and whether that's itself a data-shape bug worth separately noting (even if not fixing).

Deliverables

• Code fix + regression test (a non-string term/suggestion value exercised through safeCodeSpan).

[linear-code]

JSO-3619

[JSONbored]

Already fixed — #3441 (merged 2026-07-05T07:14:33Z) added exactly the defensive coercion this issue asks for: safeCodeSpan/promptText in review-enrichment/src/render-helpers.ts now route through asRenderableString(value) (typeof value === "string" ? value : String(value ?? "")) before any .replace() call, with a comment citing this exact issue.

Verified rather than assumed:

• Confirmed via git merge-base --is-ancestor that this issue's one captured event (release: gittensory-rees@5279b37d..., occurred 2026-07-05T07:14:45Z, box app_start_time 06:51:34Z) is from a container built from a commit that predates the fix — the event is the last pre-fix occurrence, not a post-fix recurrence.
• Deliverable feat(docs): add install site and mcp diagnostics #1 (code fix + regression test) is done: review-enrichment/test/render-helpers.test.ts already covers safeCodeSpan/promptText with undefined/null/number/array/object inputs, plus a renderBrief test that reproduces the exact stack trace shape (a { term: undefined, suggestion: 42 } terminology finding rendered without throwing).
• Deliverable chore(release): prepare public gittensory launch #2 (which analyzer/shape produces a non-string term/suggestion): review-enrichment/src/analyzers/terminology.ts's own scanTerminology is statically typed { term: string; suggestion: string } today — no non-string is possible from its current code path. The regression test's own comment already documents the working theory: a malformed entry from "a future config-driven term table or an upstream payload drift," i.e. this is a boundary-hardening fix (analyzer findings are loosely-typed data flowing through as never casts in render.ts/registry.ts, not something render-helpers.ts controls), not a fix to one specific producer — matching the existing bytesLabel defensive-guard convention this file already uses.

Sentry: zero occurrences since the fix shipped and deployed. No code change needed.