Instrument urls built from a JavaScript undefined (BL-16666)

[JohnThomson]

What this is

Sentry issue 2699459502 has years of "Cannot Find
File" reports for paths like C:/Users/<user>/AppData/Local/Temp/undefined.

BL-16577 framed these as C# building a temp path from a name that was undefined. That framing is
wrong, and a guard there would catch nothing. What actually happens is that some front-end code
does the equivalent of element.src = aVariableThatIsUndefined: the DOM turns the value into the
text "undefined" and asks the server for a file by that name. The server can only report that a
file called undefined is missing — never who asked — which is why finding BL-16447, the one
instance we have fixed, took so much guessing.

This does not fix any particular instance. It makes the next one name itself.

Two other things fell out of the investigation and are worth knowing:

• The temp folder is incidental. A bare "undefined" src resolves against the document's base url,
  and ShouldReportFailedRequest suppresses reports for anything under the current book folder — so
  these bugs are invisible when they happen on a book page. Everything reaching Sentry came from
  documents Bloom writes into temp and navigates to. We have been seeing a filtered slice.
• React src={undefined} is safe (React omits the attribute). Only the stringifying forms bite:
  el.src = x, setAttribute("src", x), new Audio(x), and template literals.

Layer A — server side, with the referrer

Referer now flows through IHttpListenerRequest → IRequestInfo → the report, so a bogus request
names the page that issued it.

undefined/null/NaN are matched as a whole path segment, case-sensitively, so a real
undefined.png, a folder called undefinedThings, or a file called Undefined are untouched.

This will increase reported volume. These reports are no longer suppressed under the current book
folder — that suppression is exactly what was hiding most instances. That is the intent, and the
extra reports should be actionable, but whoever watches Sentry should expect it.

Layer B — front-end interception, for the stack

New lib/undefinedUrlDetector.ts, installed from lib/errorHandler.ts — the module every bundle's
root already imports, so coverage is automatic. It intercepts src assignment,
setAttribute("src"), fetch and XMLHttpRequest.open, and reports with a JavaScript stack, which
names the offending line.

It is deliberately passive: it reports and lets the assignment proceed. The stack is what we
need and we get it either way, so there is no reason to change what the app does. (The plan called
for throwing in Debug/Alpha; I left that out for the same reason. Easy to add.)

Two things worth knowing if you change this later:

1. The check takes the value, not a string. At img.src = x the value arrives as the real
   undefined — the DOM stringifies it inside the native setter. My first version checked strings
   only and therefore caught nothing at the assignment site; the tests caught that.
2. fetch/XHR had to be wrapped too. BL-16447 came in through WaveSurfer fetching the url
   rather than putting it on an element, so element interception alone would have missed the one
   case we actually know about.

It also reports each distinct problem once, capped at 10 per session — each report is an http post,
and these bugs live in components that re-render.

Worth a careful look

• The merge with master had one conflict, in ReportMissingFile: PR Add diagnostics for missing files requested by bare name (BL-16577) #8171 (now landed) added
  GetBareNameDiagnostics to the same format call this adds extraDiagnostics to. I kept both —
  they answer different questions, and a bare undefined request legitimately raises both.
• The fetch wrapper calls through on window, not this. A bare fetch(url) in a module gives
  this === undefined, and the browser rejects fetch invoked on anything but the window — that would
  have broken every fetch in Bloom.

Testing

• C#: 78 pass across BloomServerTests, RequestInfoTests, BloomFileLocatorTests (13 new).
• Front end: 13 new tests in undefinedUrlDetectorSpec; full vitest suite green.
• typecheck, lint clean; production bundle compiles via build/agent-vite.sh (worth doing — this
  touches a module every bundle imports).

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16666 (split from
https://issues.bloomlibrary.org/youtrack/issue/BL-16577)

Devin review

---

This change is