Telemetry uploads can be held back under a server-controlled flush policy

What

• A new "served policy" hold lets a remote-configured flush policy delay uploading certain internal telemetry events instead of sending them right away. The policy can specify a max age, max bytes, max event count, which event types must always be flushed, and whether to flush on an assistant turn or when sampling ends.
• A new transcriptRowMayWait check decides, per event row, whether it can wait — plain assistant/user transcript turns can be held, while events carrying tool results or meta/virtual/compact-summary rows are always sent right away.
• The CCR (client-controlled reporting) worker also gained a separate hold for stream events: when dropUnwatchedStreamEvents is enabled, stream-delta telemetry is dropped (not buffered) and counted when no subscriber/viewer is present, and logging now records when this dropping starts and resumes as a watcher returns or leaves. A warning log fires if a policy-held session closes with undelivered events still queued.
• The underlying schema that validates flush policies was reworked: the field that used to validate per-model token/effort configuration now validates the event-buffer flush policy fields (max_events, max_age_ms, max_bytes, flush_on_sampling_end, flush_on_assistant, must_flush_types, policy_version).

Why This lets Claude Code's telemetry backend control, from the server side, how aggressively the client batches and delays event uploads, reducing unnecessary network traffic while still guaranteeing important events (like tool results) are never delayed.