Sentry: bare `NOT_FOUND` errors with no request context

What we're seeing

Sentry is periodically capturing an error like this:

Error
NOT_FOUND

with no request path, method, or other identifying context attached to the
event — just the bare exception.

Likely source

platform/src/server.ts's global onError hook reports every error Elysia
(the HTTP framework this server is built on) raises, with no filtering:

app.onError(({ error }) => {
  captureException(error);
});

Elysia throws its own NotFoundError (code: "NOT_FOUND", status: 404)
whenever a request hits a route that doesn't match anything — this is
generic framework behavior for any unmatched path. It's plausible that's
what's landing in Sentry here, but the pasted event alone doesn't confirm it
or say what path/client triggered it.

Open questions for whoever picks this up

• Is this actually Elysia's routing NOT_FOUND, or something else entirely?
• Check the Sentry issue's Request tab (not just breadcrumbs) for the actual
  URL/method — is it junk/scanner traffic, or a real client (e.g. Lightning)
  hitting a path that should exist?
• How frequent is this — one-off noise, or a recurring pattern worth tracing
  to a specific caller?
• If it does turn out to be routine unmatched-route traffic, is it worth
  excluding from Sentry reporting (e.g. filtering on error.code === "NOT_FOUND" in the onError hook), or should the noise stay visible for
  volume/monitoring reasons?

Not yet decided

No fix has been agreed or applied — this is a triage note for someone with
more context on Apollo's error-reporting conventions to investigate and
decide the right approach.

Start in platform/src/server.ts and inspect the global onError hook that sends errors to Sentry. Check the Sentry issue's Request tab to determine whether the NOT_FOUND error is Elysia routing noise and identify its frequency and caller. Done means documenting the cause and agreeing on whether the existing reporting behavior should change.