telemetry: add privacy-safe cached PostHog feature flags

[caezium]

Follow-up to #321. Burrow deliberately removes posthog-ios from the launch path in the startup-recovery patch, so feature flags should return only after they have a separately reviewed privacy and failure model.

Scope

• support gradual rollout and product/UI experiments with baked-in conservative defaults
• cache the last accepted flag values locally and make startup independent of PostHog availability
• fetch and evaluate flags entirely on Burrow's private background telemetry queue, without a main-run-loop timer
• emit fixed-name, documented exposure events without user content or arbitrary properties

Required guardrails

• use the existing Store.telemetryEnabled gate; an opted-out launch must not read the flag cache or contact PostHog
• never use remote flags for cleaning/deletion behavior, permissions, security controls, signing/notarization, Sparkle verification, launch recovery, or telemetry consent
• never add session replay, screenshots, autocapture, element trees, logs, PostHog error tracking, person profiles, or automatic network/file/UI instrumentation
• accept only an allowlist of known flag keys and typed values; ignore malformed/unknown payloads
• bound cache size and age, use HTTPS only, keep retries serialized/backed off, and fall back locally on every failure
• document the exact request fields, stored cache, flag keys, defaults, and exposure events in TELEMETRY.md and SECURITY.md

Acceptance criteria

• unit tests cover opt-out inertness, stale/malformed cache behavior, unknown keys, network failure, and conservative defaults
• Greenlight remains clean and the privacy manifest is re-reviewed against the final request/event fields
• rollout is validated with a harmless UI-only flag before any broader use