fix-errors

When fixing an unhandled error from the telemetry dashboard, the issue typically contains an error message, a stack trace, hit count, and affected user count. ## Approach ### 1. Do NOT fix at the crash site The error manifests at a specific line in the stack trace, but **the fix almost never belongs there**. Fixing at the crash site (e.g., adding a `typeof` guard in a `revive()` function, swallowing the error with a try/catch, or returning a fallback value) only masks the real problem. The invalid data still flows through the system and will cause failures elsewhere. ### 2. Trace the data flow upward through the call stack Read each frame in the stack trace from bottom to top. For each frame, understand: - What data is being passed and what is expected - Where that data originated (IPC message, extension API call, storage, user input, etc.) - Whether the data could have been corrupted or malformed at that point The goal is to find the **producer of invalid data**, not the consumer that crashes on it. ### 3. When the producer cannot be identified from the stack alone Sometimes the stack trace only shows the receiving/consuming side (e.g., an IPC server handler). The sending side is in a different process and not in the stack. In this case: - **Enrich the error message** at the consuming site with diagnostic context: the type of the invalid data, a truncated representation of its value, and which operation/command received it. This information flows into the error tele...