flutter-observabilitylisted

# Flutter Observability Make production failures diagnosable without collecting unnecessary user data. Preserve an existing Sentry, Crashlytics, OpenTelemetry, Dynatrace, Datadog, or other telemetry stack unless the user requests a migration. ## Preflight Read SDK constraints, entrypoints, flavors/environments, and the complete existing telemetry and delivery wiring before diagnosing a cause or prescribing changes: SDK initialization, error hooks, consent/privacy rules, network and navigation instrumentation, isolate usage, obfuscation, symbol retention/upload, CI, and release identity. Do not infer the root cause from dashboard symptoms alone. When repository or backend evidence is unavailable, lead with the exact artifacts and backend evidence still required, state that diagnosis remains pending, and keep any remediation conditional. Start from a concrete diagnostic question or incident; do not instrument every event by default. Define a small operational event contract: stable event name, severity, timestamp, release/build, environment, platform, correlation identifier, outcome, duration where meaningful, and a bounded set of redacted attributes. Keep user content, tokens, credentials, payment data, and raw request/response bodies out of telemetry. Every instrumentation plan must explicitly cover all five governance controls: redaction, consent, sampling, backend retention/access, and bounded offline buffering. State which controls live in client code and which must b