chore: update posthog dependency to 2.5.0

[T0ha]

Summary

• Bumps posthog from 2.4.0 to 2.5.0 (was locked at 2.4.0 while mix.exs allowed up to ~> 2.0).
• Tightens the mix.exs constraint from ~> 2.0 to ~> 2.5.0 deliberately: every posthog release from 2.6.0 through the current 2.10.3 fails to compile on Erlang/OTP 28 (this repo's toolchain per .tool-versions). PostHog.Config bakes compiled ~r// regex defaults into a module attribute (source_code_exclude_patterns, added in 2.6.0 for the error-tracking source-context feature); on OTP 28, Regex.compile/1 produces a struct holding a Reference (an opaque NIF resource), and Elixir cannot escape a Reference into a module attribute — mix compile fails with ArgumentError: cannot escape #Reference<...>. I verified this by bisecting posthog-elixir tags 2.5.0 through 2.10.3; the bug is unreported upstream as of 2026-07-04. mix.exs now pins to ~> 2.5.0 (the last known-good release) with a comment explaining why, so we don't silently upgrade into the broken range again.
• Also pulls in the transitive dependency bumps posthog 2.5.0 requires: req, finch, mint, jason, telemetry, ecto, plug, decimal, castore (all minor/patch, resolved by mix deps.update posthog).

Test plan

• mix compile — compiles cleanly (only a pre-existing, unrelated warning in tg_webhook_handler.ex that's present on main too)
• mix test — 250 tests, 0 failures
• iex -S mix — boots cleanly, PostHog application loads at 2.5.0
• mix dialyzer — 0 errors
• mix format --check-formatted — clean

🤖 Generated with Claude Code

[claude]

Review

Reviewed the diff (mix.exs + mix.lock only). Solid, well-scoped dependency-bump PR.

Code quality

• The comment on mix.exs:80-85 explaining why the constraint is pinned to ~> 2.5.0 instead of the usual "latest minor" is exactly the kind of non-obvious rationale worth keeping in-repo — good call recording it inline rather than only in the PR description, since the PR description won't be visible to someone reading mix.exs in six months.
• Comment lines stay within the 80-char limit per the repo's style guide.
• Confirmed locally: .tool-versions pins erlang 28.0.2, so the OTP 28 compatibility concern driving the ~> 2.5.0 pin is real for this project's actual toolchain, not a hypothetical.

Potential bugs/issues

• None found in the diff itself — it's a pure dependency/lockfile change with no application code touched.
• Worth double-checking upstream once in a while: the PR notes the Regex/Reference escaping bug is unreported upstream as of 2026-07-04. Since there's no tracking issue link, this fix is easy to forget about. Consider filing the bug against posthog-elixir (or linking to one if you already did) so there's an external signal for when it's safe to bump past 2.5.x, rather than relying on someone noticing the comment during a future dependency update.
• Double checked that none of the existing mix.exs constraints on the transitively-bumped deps (finch ~> 0.13, jason ~> 1.2, req ~> 0.5, ecto_sql ~> 3.10, etc.) conflict with the new lockfile versions — they don't, all bumps are compatible minor/patch releases.

Performance

• No performance-relevant changes; this is a dependency bump only.

Security

• No security concerns. Versions move forward (no downgrades), and the tightened ~> 2.5.0 constraint is strictly more conservative than the previous ~> 2.0, so there's no risk of silently picking up an untested major/minor version.

Test coverage

• N/A for a lockfile/dependency-constraint change — existing test suite is the right coverage here, and the PR description reports mix test (250 tests), mix dialyzer, mix compile (no warnings), and mix format --check-formatted all passing, plus a manual iex -S mix boot check. That matches this repo's feature-workflow/pr-workflow checklist.
• One optional suggestion: since the whole point of this PR is "avoid the OTP 28 compile crash," it could be worth a one-line note in docs/ (or wherever posthog integration is documented, if anywhere) cross-referencing the mix.exs comment — but this is a nice-to-have, not a blocker, given the comment is already right next to the pinned version.

Overall: LGTM. Small, well-justified, well-tested change.