tech-debt: document + tune transcript shutdown timeout value (WB3b MEDIUM)

[baladithyab]

Source: docs/reviews/audio-graph-wave-b-review.md WB3b MEDIUM

Current: Hardcoded `Duration::from_secs(5)` in writer shutdown timeout.

Concern: "Chosen empirically" — not validated with real-world data. Could be:

• Too short: healthy fsync on a large transcript (10+ MB) + slow disk (HDD / network filesystem) might legitimately exceed 5s, causing the hard HIGH double-drop path.
• Too long: a wedged disk (NFS stall, drive died) causes `new_session_cmd` to block the UI for 5s which is user-visible jank.

Action:

1. Add instrumentation (log fsync duration histogram at INFO level)
2. Collect 1-2 weeks of real usage data
3. Tune timeout to p99 of healthy flushes + safety margin
4. Document the chosen value in a `// Chosen because...` comment citing the data

Effort: 1h initial instrumentation + 2 weeks wait + 30min tune.

[baladithyab]

Phase 1 landed in commit f8a0926: INFO-level timing instrumentation is now emitted on every session rotation.

Two log keys to watch for:

• transcript_writer.final_flush elapsed_ms=… outcome=… — kernel-side cost of the writer thread's final BufWriter::flush
• transcript_writer.shutdown_join elapsed_ms=… timeout_ms=… joined=… — caller-observed wall-clock from shutdown signal to JoinHandle ready

Together they separate "what the kernel's doing" from "what the caller waits for" (queue drain + flush + thread teardown).

Phase 2 (1-2 weeks from now): grep logs for these keys, compute p50/p95/p99, set TRANSCRIPT_WRITER_SHUTDOWN_TIMEOUT to p99 + ~1s safety margin, annotate the constant with the chosen rationale.

Reopening after the data-collection window. Leaving issue open as a tracker.