feat(web): records widget — biggest-trade + longest-survival-streak

[ntatschner]

Plan-3b follow-up #2 — Records widget expansion (2 of 3 records added).

The original Records widget shipped with longest-session and busiest-
session-by-event-count and explicitly noted "More records (deadliest,
biggest trade, longest streak) ship in Plan 3b". This PR lands 2 of
those 3. Deadliest session is deferred — it needs per-session
death aggregation on the server, which doesn't exist yet.

What the user sees

Compact (single line)

Before: `Longest session 4h 12m · Busiest 23,418 events`

After: `Longest session 4h 12m · Survival 12d 6h`
(falls back to `Busiest …` when the user has < 2 deaths in the
recent window, so the original behaviour is preserved when survival
streak isn't computable)

Expanded (full list)

Before: 2 rows + a "more records ship in Plan 3b" note.

After: 4 rows + a more honest "Deadliest session pending — needs
per-session death aggregation on the server" footnote.

Record	Source
Longest session	`getSessions` (max `ended_at - started_at`)
Busiest session	`getSessions` (max `event_count`)
Longest survival streak	`listEvents({ event_type: 'player_death', limit: 500 })` — max gap between consecutive timestamps
Biggest trade	`getCommerceRecent(token, 500)` — max `quantity` of any `status === 'confirmed'` row

Caveats documented in code

• `fmtTimeSpan` switches to days+hours for spans ≥ 1 day. Without it,
  a 60-day survival streak would render as `1442h 30m` which is
  unreadable.
• "Biggest trade" is by `quantity`, not aUEC, because
  CommerceTransactionDto doesn't expose a typed currency field.
  Comment in the file flags this.
• 500-event limit on the deaths fetch — adequate for "longest gap"
  computation in any realistic player history. Server-side per-session
  death aggregation would be more accurate but requires backend work.

Invariants honoured

• 3 parallel fetches via `Promise.allSettled` — a single endpoint
  hiccup doesn't blank the widget. Per-source rejections log with
  `call=widget.records.` for diagnostics.
• Returns `null` when all 4 records are zero — WidgetFrame supplies
  the empty placeholder.
• Owner-only via `isAvailable = () => ctx.isOwner`. Visitor widening
  follows the Plan-3b sharing-toggle work (separate PR).

Files

• `apps/web/src/app/_components/widgets/records.tsx` — rewritten;
  imports `getCommerceRecent` + `listEvents` (already in api.ts).

Test plan

• CI `Build & Test` workflow passes on ubuntu + windows
• `pnpm --filter web typecheck` clean (verified locally — exit 0)
• Manual smoke (owner, flag ON, widget enabled): 4 records
  visible in expanded view; compact view shows longest + survival
  (or fallback to busiest)
• No-data fallback: widget returns `null` when the user has no
  sessions, no transactions, and no deaths

Notes

• Draft because this is one of several follow-ups in flight.
• No backend changes. Rule 1 small-task scope.
• "Deadliest session" can become its own follow-up when there's
  appetite to add the server endpoint.