Crash reporting for the bridge, and the two silent failures it uncovered

[bharathm03]

Three fixes. The first was the request; the second and third are what looking for
evidence that the first worked turned up.

1. The bridge reports its own crashes

The host process had no crash reporting at all. It now runs @sentry/bun behind
three gates that must all hold: the user's telemetry consent, carried on the stdin
bootstrap as telemetryEnabled and read once for the host's lifetime (absent means
off, so a CLI or test host never reports); a SENTRY_DSN baked in by --define,
exactly like LICENSE_API_URL; and a scrubber that strips paths, source lines,
locals and the hostname, kept in lockstep with the app's.

Every integration that reads request bodies or source off disk is excluded, with a
per-name reason in the file. OnUncaughtException/OnUnhandledRejection are
deliberately kept — they are what stamps a fatal handled: false, and a
hand-rolled captureException reports the same crash as generic/handled: true.
Their contract has a second half in index.ts: the SDK re-counts the other
uncaughtException listeners at crash time, so it defers to our teardown only
while one of ours is registered.

A DSN the SDK silently refuses

Sentry.init never throws and never returns a status. A DSN it rejects leaves a
transport-less client on which every captureException — and flush — still
succeeds, sending nothing.

That is measured, not hypothetical:

dsn=https://k@example.invalid/antgrid-app-staging
  Invalid Sentry Dsn: Invalid projectId antgrid-app-staging
  transport: NONE     parsed dsn: null

dsn=https://k@example.invalid/42
  transport: present  parsed dsn: {... "projectId":"42"}

The JS SDKs require a numeric project id; errex issues slugs, so the DSN CI
bakes in is refused outright and this feature would have shipped completely inert.
Init now verifies getClient()?.getDsn() and logs at error instead of trusting
itself. sentry-dart takes the last path segment as an opaque String, which is
why only this side is affected.

Action needed before this reports anything: the bridge needs a numeric project
id. errex has none — a real key against /api/1/ and /api/42/ returns 401,
against /api/antgrid-app-staging/ returns 400.

2. Windows shipped with no native crash capture

sentry_flutter never assigns nativeDatabasePath, and sentry-native then falls
back to .sentry-native relative to the current working directory. That is
unwritable in exactly the configuration we ship: a Store-launched MSIX gets
C:\Windows\System32 as its cwd, and its own install dir under WindowsApps is
read-only. sentry_init fails, and native capture is absent with nothing to notice
it by — no crashpad handler, no database, and (auto-session-tracking being a native
option) no release-health sessions either.

Measured on the shipped 1.20698.1008 package: sentry.dll loaded, no
.sentry-native anywhere on the machine, no crashpad_handler process. The
only .sentry-native on disk belonged to an unrelated app, sitting in %TEMP% —
which is what confirmed the cwd-relative default.

Dart-level reporting was unaffected throughout, which is why production kept
receiving Dart fatals while every native crash was lost.

Also turns options.debug on outside release builds. The SDK reports its own init
failures at debug level and nowhere else, which is the entire reason this went
unnoticed: a broken native layer looks exactly like an app that never crashed.

docs/release/build.md records that errex has no symbol-upload endpoint —
sentry-cli's chunk-upload and legacy dsyms paths both 404 while implemented routes
answer 401 — so a sentry-cli upload-dif step would only fail in CI.

3. A production fatal, traced to our code

ConcurrentModificationError: Concurrent modification during iteration: _Set len:4.
culprit: _CompactIterator.moveNext  <-  FocusManager.applyFocusChangesIfNeeded
level: fatal    events: 3    release: antgrid@1.20693.1003+1003

Every frame was in_app: false, which made it read as a framework bug. It is ours.

applyFocusChangesIfNeeded notifies with for (final node in _dirtyNodes) node._notify(),
and FocusNode.dispose detaches, which makes FocusManager._markDetached do
_dirtyNodes.remove(node) — mutating the Set being iterated. The chain:

onFocusChange: (hasFocus) { if (!hasFocus) _commitDetached(); }   session_row.dart
  -> detached(...) -> Future<void>.sync(action)     runs the body NOW
     -> _commitEdit()  synchronous up to its first await
        -> _exitEdit()  called BEFORE `await warmServiceFor(...)`
           -> _editFocus?.dispose() -> _markDetached -> _dirtyNodes.remove(node)

_exitEdit now clears the fields first and disposes in a microtask, so the
notification unwinds before the detach. Fixed there rather than at the callback so
both commit triggers — Enter and blur — are covered.

Repro: rename a session, then click away to blur the field.

Testing

Gate	Result
bun run --filter antgrid-bridge test	3246 pass / 0 fail
bridge tsc --noEmit	clean
flutter test	3141 pass / 0 fail
flutter analyze	No issues found
dart format	clean
compiled bridge binary + smoke-hook-binary.ts	SMOKE=0

The rename regression test drives the real row — double-tap to rename, move focus
away, assert no exception. Reverting the fix makes it throw the same
ConcurrentModificationError, verified.

Still open

antgrid-app-staging returns a generic 400 invalid envelope to everything —
an empty body, the string not-an-envelope, and a byte-exact sentry.dart/9.22.0
envelope captured off the wire and replayed. Production accepts real events, so this
looks like that project not being provisioned rather than a client problem. No test
event was ever delivered.

Separately: that production event has timestamp 2026-08-29T06:14:18Z but
received_at 2026-09-02T04:37:01Z. If received_at is genuine ingest time, reports
are arriving four days late and are not usable for monitoring.