feat: add posthog telemetry

[avallete]

Closes: CLI-1243

[coveralls]

Coverage Report for CI Build 24070999748

Coverage increased (+0.4%) to 63.763%

Details

• Coverage increased (+0.4%) from the base build.
• Patch coverage: 181 uncovered changes across 10 files (462 of 643 lines covered, 71.85%).
• 6 coverage regressions across 2 files.

Uncovered Changes

File	Changed	Covered	%
cmd/root.go	39	0	0.0%
internal/telemetry/service.go	156	129	82.69%
cmd/root_analytics.go	126	101	80.16%
cmd/telemetry.go	29	6	20.69%
internal/login/login.go	35	16	45.71%
internal/telemetry/state.go	74	58	78.38%
internal/telemetry/client.go	84	73	86.9%
internal/link/link.go	36	26	72.22%
internal/telemetry/project.go	43	36	83.72%
internal/start/start.go	8	4	50.0%

Coverage Regressions

6 previously-covered lines in 2 files lost coverage.

File	Lines Losing Coverage	Coverage
internal/utils/git.go	5	57.14%
cmd/root.go	1	8.84%

---

Coverage Stats

Relevant Lines:	15302
Covered Lines:	9757
Line Coverage:	63.76%
Coverage Strength:	6.89 hits per line

---

💛 - Coveralls

[seanoliver]

Tested locally with PH staging project and everything looks great!

The env_signals property is 🔥 — this is going to be super useful for segmentation.

[pamelachia]

one thing from the telemetry side: the 4 events are defined as inline strings at each call site. on the frontend we have telemetry-constants.ts that acts as a registry for every event with documented properties for each event, which makes it easy to see what's being tracked, keep naming consistent, and lets data people know what to expect without reading through the Go code.

would it be possible to add something similar for the CLI? even just a constants file in internal/telemetry/ with all event names and expected properties in one place. makes it way easier for us to track what exists and catch naming issues before they ship