feat!: MCP no longer relabels the client SDK identity

[eli-r-ph]

💡 Motivation and Context

Stacked on #1030. Capture v1 sets $lib from a per-request header, so one client has one identity. In 7.x, MCP instrumentation relabeled the whole client as posthog-python-mcp, so every event and flag request from the app reported that name. In 8.0 the client always reports posthog-python.

Changes

• MCP instrumentation no longer changes $lib, the PostHog-Sdk-Info header or the flag request User-Agent.
• Removes _lib_identity.py, POSTHOG_MCP_LIB_NAME, Client._set_library_identity and the request code that only served them.
• The MCP README and migration guide say to find MCP traffic with the $mcp_* events and properties.

Note

SDK Health and flag analytics will count MCP servers as posthog-python after 8.0.

💚 How did you test it?

• A client passed to instrument() keeps $lib: posthog-python; bringing back the relabel fails the test.
• A PostHogMCP client sends PostHog-Sdk-Info: posthog-python/<version>.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Written with Cursor (Claude) under the direction of the assignee.

🤖 Generated with Claude Code

[dustinbyrne]

ok, glad to see we're retaining $lib and $lib_version as queryable properties. from my standpoint, that was my main concern.

worth a look from @PostHog/mcp-analytics given the $lib overwrite is part of their SDK specification: https://github.com/PostHog/sdk-specs/blob/f238b169dee7897dd55074061f600a2fa8bb4925/openspec/specs/mcp-analytics/spec.md#L529-L543

[lucasheriques]

makes sense from mcp-analytics side, esp. if this is better for the property long term. we can add a new $mcp_* property indeed if needed, thanks for addressing and sorry for causing the issue in first place 😅

will update on the spec too