Diagnostics for the stuck-room bug: party server logging, a room log watcher, and a ?debug health endpoint - #611

`partykit tail` accepts a server-side `--search <string>` filter (it maps
to the Cloudflare tail API's `query` text match), and every diagnostic
line the server emits carries `room=<id>`. That makes it possible to
narrow the log firehose to a single event when someone reports a problem
in the field.

This wraps that up so troubleshooting is one command:

    yarn watch:room https://ddrdraw.surge.sh/#/e/abc123
    yarn watch:room abc123

The room id is the `:roomName` segment of the event URL, so a reporter's
link can be pasted verbatim. Beyond filtering, the script correlates the
lines to answer the question the logging was added for:

- prints a compact one-line-per-event timeline
- re-filters client side on an exact `room=` match, since the server-side
  search matches whole invocations and is not anchored
- alerts when a room restarts still holding unsettled storage writes
  (the "put didn't flush before eviction" suspicion)
- alerts when an onStart hydrates a snapshot that doesn't match the last
  state we saw an action apply — the snapshot-reverted signature itself
- surfaces upsert/hydrate errors, uncaught exceptions, and non-ok
  invocation outcomes
- prints a tally and a verdict on exit

A tail session expires server-side and the partykit CLI does not
reconnect, so the tail is supervised and restarted with exponential
backoff, giving up after 5 consecutive failures that never stay up (which
is what a login or project-name problem looks like). Tail has no backfill,
so gaps are printed rather than papered over, and findings that straddle
one are handled honestly: writes in flight when the tail dropped move to
an "outcome unknown" tally instead of being reported as lost, and
baseline-dependent alerts are annotated as uncertain until a freshly
observed action re-establishes the baseline.

`--out <file>` appends the same timeline without colour codes, so the
watcher can be parked for a whole event and read afterwards.

Flags: --out <file>, --no-reconnect, --verbose, --raw, --all; anything
after `--` is forwarded to `partykit tail`, e.g. `-- --preview my-preview`.

Verified against synthetic tail streams covering the bug shape, a healthy
room, the error/exception paths, and a mid-stream tail drop: alerts fire
only where warranted, the gap qualifier appears only after an actual gap,
and the --out file is written clean. oxfmt passes; scripts/ is outside the
oxlint and tsc include globs.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KmuaLNBXFwzHU6BUd1vGtD

Hosted PartyKit gives no persistent logs: `partykit tail` is a live
websocket with no backfill, and the logpush/tailConsumers/analytics
config keys all require your own CLOUDFLARE_ACCOUNT_ID + API token, which
a *.partykit.dev deploy does not have. So troubleshooting a report that
arrives hours after the fact needs the room to be able to describe its
own health on demand.

`GET /parties/main/<room>?debug` now returns a health snapshot. The
default GET response is untouched — the debug branch is opt-in via the
query param, so clients calling getPartykitState() are unaffected.

The snapshot answers "did this room's persisted snapshot stop advancing?"
in one request by comparing three views of the state:

- memory:   the live store's fingerprint
- storage:  read back from room storage, with matchesMemory
- supabase: the persisted row plus its updated_at, with matchesMemory

plus per-instance diagnostics: how it hydrated (source/when/fingerprint),
storage write tallies (started/ok/failed/unsettled), supabase upsert
tallies, last action, last error, and connection count. A `warnings`
array and `healthy` boolean make it self-interpreting; notably it calls
out storage and supabase disagreeing, since onStart prefers storage and a
stale value there pins the room to an old checkpoint indefinitely.

Caveat documented in the code: requesting this instantiates the room if it
was evicted, so the counters describe the instance you just woke. The
storage/supabase comparison is the part that survives an eviction.

Verified against a local `partykit dev`: the plain GET still returns raw
AppState unchanged; after driving two actions over a websocket the
snapshot reports seq=2, storage matchesMemory=true, 2 started / 2 ok /
0 unsettled, healthy=true. Re-run with a deliberately stalled storage
write reproduced the production shape and reported memory=346 vs
storage=291, unsettled=1, healthy=false with both expected warnings.
tsc --noemit, oxlint, and oxfmt pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KmuaLNBXFwzHU6BUd1vGtD

When an organizer hits sync trouble mid-event, we currently have no way to
find out what their client saw. Server logs cover the room's side, but the
client's view — when it dropped, what it was still holding, what got
refused — was only in a devtools console nobody has open at a venue.

Adds a diagnostics panel reachable from the app header in event mode
(hamburger → "Connection diagnostics"), gated with EventModeGated so it
doesn't appear in classic mode. It shows:

- a plain-language connection log with local timestamps, covering
  session start, connect/reconnect, disconnect, catch-up replays,
  heartbeat loss, resyncs, blocked changes, rejected actions, and
  actions abandoned after repeated attempts
- a live list of changes not yet saved to the server, with the action
  type, how long each has been waiting, and how many send attempts
- a copy button that puts a report on the clipboard: room, timestamp
  with UTC offset, user agent, pending list, then the whole log
- a prompt asking the user to post it in a thread on the Discord server

The log lives in `src/party/diagnostics.ts`, deliberately outside redux for
the same reason `connection-status.ts` is: anything in the store gets
broadcast to the room and persisted into every event's snapshot, and a
per-client debug log is neither shared state nor something to write there.
It is a 200-entry ring buffer read through useSyncExternalStore, so the
panel updates live while open.

`SyncManager` grows a `pendingActions` getter (and records when each
pending entry was first sent) so the panel can read the real pending list
rather than duplicating that state.

DISCORD_INVITE_URL in diagnostics-dialog.tsx is intentionally left empty: no
invite link exists in the repo, and the prompt renders fine without one
rather than shipping a URL that goes nowhere. Set it to make the link
appear.

Verified in a real browser against both dev servers, driving the actual
failure path with the workerd SIGSTOP recipe from the verify skill:
- while the server was frozen, the panel showed 2 pending event/addCab
  entries with live ages and attempt counts
- after recovery the log read: action-abandoned x2, heartbeat-lost ("no
  reply to 2 pings; forcing a reconnect"), disconnected, then
  reconnected (seq 3)
- the copy button produced the full report on the clipboard and flipped
  to "Copied!"
tsc --noemit, oxlint, and oxfmt pass; webpack builds clean.

New UI strings are in en and ja; the Japanese is a best effort and should
get a native-speaker pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KmuaLNBXFwzHU6BUd1vGtD

The invite already existed in the about/credits dialog; it just wasn't
found earlier because a shortened discord.gg URL doesn't contain the word
"discord" in any searchable form beyond the host.

Rather than repeat the URL in a second place where the two could drift,
this extracts it to src/external-links.ts and has both the about dialog and
the diagnostics panel read from there. The diagnostics prompt now always
renders the link, so the empty-string fallback branch is gone.

Verified in a browser: the diagnostics panel renders "Open Discord" ->
https://discord.gg/QPyEATsbP7 with target=_blank, and the about dialog
still carries the same link after the refactor.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KmuaLNBXFwzHU6BUd1vGtD