feat(analytics): record write-transaction commit latency

[kriszyp]

Summary

Adds transaction-commit-time, a distribution metric (mean + p90/p95/p99/p999 via the standard analytics action path) recording each write transaction's submit→settle duration.

Purpose

#592 asks for a leading indicator before write-heavy workloads hit Outstanding write transactions have too long of queue, please try again later (503). That rejection fires when the oldest outstanding commit has been outstanding longer than storage.maxTransactionQueueTime (45s default) — a latency condition, not a count. transaction-commit-time is measured on that exact clock (outstandingCommitStart → settle), so a rising p99/p999 is the direct leading indicator: it reflects transaction size/duration and the shared storage-engine write path, not just per-thread submission concurrency.

Recorded per commit attempt — a transient-conflict retry rejects and re-issues commit(), and the overload check's own outstandingCommit re-arms per attempt the same way, so this matches the failure semantics exactly.

Design note (dependency inversion)

resources/DatabaseTransaction.ts does not import the analytics/server modules. It exposes setCommitLatencyRecorder(recorder); resources/analytics/write.ts registers the recorder at load. This mirrors the existing replicationConfirmation callback-registration pattern in the same file and avoids a circular import between the storage layer and the analytics/server layer. The recorder is wrapped so a metrics failure can never throw into the floating .then() or disturb the commit path.

Attention

• Companion docs PR: docs(analytics): document transaction-commit-time metric documentation#572
• Sibling PR (secondary/complementary metric, not required for this one): feat(analytics): expose write/read transaction queue depth (count) metrics #1689 — a per-thread in-flight transaction count. Kris flagged that count doesn't capture transaction size/duration or the shared write-path queue the way latency does, so it's split out as an independent, optional PR.
• Cross-model review (Codex + Gemini) caught three real issues in an earlier revision of this diff — an unhandled-rejection risk on the floating .then(), a circular-import risk (DatabaseTransaction → Server), and a test binding issue. All three are resolved by the registration-based redesign above (verified by re-running build/lint/tests); no open concerns remain from that review.

Generated by Claude Opus 4.8.

[claude]

Reviewed; no blockers found.

[heskew]

Latency recording is cheap on the commit path (one .then on the existing promise, early-return when unset, try-catch so analytics can't break a commit). Thenable guard added, circular import avoided via registration. Tests cover recording + unregistered-recorder no-throw. LGTM.

_{🤖 Reviewed via cross-model pipeline; approved by @heskew.}