Pool saturation makes its own telemetry unreliable (partial evidence during incidents)

During the PLUTO-692 incident (2026-08-11T23:45Z), Vercel runtime logs show the applog logger's OWN appEvents write also timed out — the pg pool was saturated enough to lose the diagnostic write, not just the notification write. db-pluto-cc's 'one error-tier row in that window' is a LOWER BOUND on what actually happened, not a full account. Worth deciding whether pool sizing (currently max=2, connectionTimeoutMillis=5000 per PLUTO-93) needs revisiting, or whether telemetry needs a path independent of the app pool. Surfaced by coder-pluto-cc, 2026-08-11.