feat(analytics): attach app version to all custom events

[andrewm4894]

Problem

We send custom events to PostHog from the Code app, but none of them carry the PostHog Code version. That makes it impossible to answer version-related questions from product analytics — e.g. "are users stuck on old versions?" or "did auto-updates stop landing?" (see the auto-update reports in Slack). The version was only available in OTel logs as service.version, not on events.

Changes

Attach the app version (getAppVersion() / POSTHOG_CODE_VERSION, sourced from app.getVersion()) to every custom event:

• Main process (posthog-analytics.ts): merge app_version into the properties of every trackAppEvent(...) capture and every captureException(...).
• Renderer: add a focused registerAppVersion(version) that registers app_version as a PostHog super property (so it rides along on all subsequent events, including exceptions). App.tsx fetches the version via the existing os.getAppVersion tRPC query at startup and registers it.

Kept analytics.ts free of any trpcClient import (the fetch lives in App.tsx) to avoid a module-load-time tRPC/ipcLink dependency that would otherwise break renderer unit tests.

No UI changes.

How did you test this?

• Added posthog-analytics.test.ts (main): asserts app_version is on tracked events, on captured exceptions, and coexists with caller-supplied props.
• Extended analytics.test.ts (renderer): registerAppVersion registers the super property after init and no-ops before init.
• Ran the full code app suite: pnpm --filter code test → 1516 passed.
• npx biome check and tsc -p tsconfig.web.json clean on touched files; pre-commit typecheck hook passed.

Publish to changelog?

no

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/code/src/main/services/posthog-analytics.ts:48-53
`app_version` is placed before `...properties`, so a caller that accidentally or intentionally includes an `app_version` key in the properties bag will silently overwrite the value returned by `getAppVersion()`. Given the explicit goal of making this field authoritative on every event, placing it after the spread ensures the system value always wins.

```suggestion
    properties: {
      team: "posthog-code",
      ...properties,
      app_version: getAppVersion(),
      $process_person_profile: !!currentUserId,
    },
```

### Issue 2 of 2
apps/code/src/main/services/posthog-analytics.ts:97-101
Same ordering issue in `captureException`: `app_version` is set before the spread, so any `app_version` key inside `additionalProperties` will silently replace the real version in the captured exception data.

```suggestion
  posthogClient.captureException(error, distinctId, {
    team: "posthog-code",
    ...additionalProperties,
    app_version: getAppVersion(),
  });
```

_{Reviews (1): Last reviewed commit: "feat(analytics): attach app version to a..." | Re-trigger Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9519c2e583

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[andrewm4894]

@k11kirky trimmed the excessive comments down to one concise line each (kept just the non-obvious bit about posthog.reset() wiping super properties). Ready for another look — commit: f532674