analytics-instrumentationlisted

# Analytics instrumentation ## What It Does Turns "add tracking for this feature" into the governed, documented, drift-resistant flow paqad promises: it names and documents each event as a reviewed per-event doc, governs every new event through a Decision Pause, and emits the provider tracking-call to paste into the source. ## Use This When Analytics is enabled (`analytics_instrumentation` on) and the classify-time gate wrote `.paqad/planning/analytics-decision.json` with `status: instrument` — i.e. a user-facing change in a project with a detected provider. Skip entirely when analytics is off or the change is not user-facing. ## Inputs - `project_root` — resolves the docs tree and the analytics decision sidecar. - `module`, `feature` — the module and feature slugs the event belongs to (from the module map). - `event` — the exact event name, in the project's ONE consistent convention. - `provider` — one or more analytics provider ids the event fires to. ## Procedure 1. **Name the event** in the project's one consistent convention. Read `docs/instructions/stack/analytics.md` and the module's `analytics/index.md` first, and reuse an existing event before coining a new one. Object-action + past tense is a common default, not a rule; consistency is the rule, and no variable data goes in the name. 2. **Govern a new event.** If the event does not already exist, open a Decision Pause packet in the `analytics.new_event` category (who proposed it, why, with the nam