docs: add render telemetry guide

[chiefcll]

Adds docs/articles/telemetry.md, a guide for apps that want production render telemetry, plus a sidebar entry under Advanced Topics.

Why

The renderer's fpsUpdate payload has 25+ fields and several pooling traps (sampledFrames vs renderedFrames, weighting meanActiveAnimations, pooling rates instead of sum(frames) / sum(ms)). Apps wiring it into a dashboard end up reimplementing all of that. For a fleet dashboard, two numbers answer the question "is this viewer having a good time":

Field	Question
PAGE_SETTLE_MS	How long from a route change until the new page was fully drawn, images included.
ANIMATED_FPS	How smooth motion was while something was moving.

What the page covers

• idle is the boundary for both metrics. It fires once per active-to-idle transition, and the stage stays non-idle while textures are queued, so the first idle after a route change is the moment the new page's node burst is on screen with its images uploaded. No component instrumentation and no timers.
• animatedFps rather than fps, since a screen that draws one frame for a late texture then sits still posts a rate no viewer perceived.
• Setup (fpsUpdateInterval, setTelemetrySegment, keeping segment labels low cardinality), a dependency-free tracker with an emit callback, and router wiring via useLocation.
• Which aggregate to watch per field, and the explicit handoff: when a number goes red, reproduce on device and profile there. That is why the phase fields (updateMs / renderMs / uploadMs) are deliberately not in the reported set.
• The gaps, stated plainly: a permanently animating screen never goes idle so it reports no settle time, the DOM renderer emits neither event, and pre-1.8 series are not comparable.

Docs only, no source changes.

🤖 Generated with Claude Code