[OPIK-8061] [SDK] feat: report anonymous usage analytics from the Python SDK - #7959

Adds `opik.analytics`: a one-line call that records which SDK features get
used, so we can see what to invest in. 97 events across the client, the
integrations and evaluation.

  analytics.track_event("integration", "openai")

Only the name of the API called is reported, once per run, alongside the
environment details already attached to error reports. No trace, span,
prompt or dataset contents, no API key, no project names, and no name the
user chose - a user-defined metric reports as "custom". There is no
scrubbing layer, because every payload is written out at its call site.

Events go to Comet's usage endpoint and on through Segment to PostHog, the
route the backend already uses, from a single daemon thread. Nothing about
reporting can block, slow or break calling code, and an unreachable
endpoint delays process exit by at most two seconds.

Counting is built to survive the places it usually breaks:

- Claiming an event is atomic, so threads racing on a first call report one
  copy rather than one each.
- `fork()` rebuilds the worker while keeping the record of what the parent
  reported, so a child reports its own events but never repeats its parent's.
- Opik's own calls into its own API are not reported, so `evaluate_threads`
  calling `search_threads` counts once.
- A blank workspace falls back to a hostname hash instead of an empty
  identifier, which would have filed every such install as one user. This
  also fixes the same bug in Sentry error reports, which share the identifier.

Identity and environment metadata now live in `opik/environment.py` and
`opik/environment_details.py`, read by both analytics and error tracking so
the two payloads cannot drift apart.

`OPIK_ANALYTICS_ENABLE=false` switches it off. Reporting is also skipped
under pytest so test suites make no network calls.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adding an event, the closed component vocabulary, why the level separator
is doubled, and the counting guarantees dashboards depend on.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The frontend and backend sections each walk through adding an event; the
Python one only had reference material. Covers picking the path, the
separator rule the name depends on, what may go in properties, when an
entry point should not be instrumented at all, and a verified snippet for
seeing the payload locally.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

- A forked child reused the parent's cached `pid` and `session_id`, so its
  events and error reports were indistinguishable from the parent's. The
  cache now clears on a fork hook in `environment_details`, which fixes it
  for Sentry reporting too.
- One failed request aborted the rest of the batch. The collector takes one
  event per request, so an escaping exception discarded everything queued
  behind it - and events are only reported once. Now caught per event.
- A segment built at runtime containing `__` split into levels that were
  never intended; runs of underscores are collapsed before joining.
- An empty `OPIK_ANALYTICS_URL` started a worker whose every batch would
  fail. It now disables reporting instead. Not a second opt-out.
- An event dropped by a full queue stayed claimed and was lost for the rest
  of the process; the claim is released when the hand-off is refused.
- Failures kept their DEBUG level, deliberately - our telemetry problems do
  not belong in a user's logs - but now carry `exc_info`, so they can
  actually be diagnosed when debug logging is on.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Gives us a remote off-switch. Until now a rejected request was logged and
forgotten, so a process kept sending its remaining events however many
times it was told not to - 25 events still made 25 requests against a
server answering 410 every time.

A definitive rejection (401, 403, 404, 410) now stops the process: the
worker thread exits and `track_event` returns on its first line. 429 and
5xx are deliberately excluded - they mean try later, not stop, and giving
up on those would lose events to a passing blip.

The destination can already tell versions apart: this client sends
`User-Agent: opik-python-sdk/<version>`, so a rule at the edge can retire
the whole SDK or one bad version without touching application code, and
without a credential to ship or revoke. That only stops the traffic for
versions carrying this commit, which is why it lands before release.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Our CI runs the SDK, so its runs land in the usage analytics as if they
were a user's. 127 such events reached production over three days from
this branch's builds alone, and once merged every CI run on every PR
would keep adding to that - inflating exactly the counts the analytics
exist to measure.

`OPIK_ANALYTICS_ENABLE: false` goes next to the `OPIK_SENTRY_ENABLE`
that 35 workflows already set: same scope, same intent, and set at
workflow level so every step and any subprocess inherits it.

The pytest rule cannot cover this on its own. It tests for pytest in
`sys.modules`, so it only sees the process pytest is running in - a
subprocess spawned by a test reports as normal, which is how these
escaped. Verified: with the variable set, a grandchild process with
pytest nowhere in its tree sends nothing, where the same run sends 41
events without it.

`installation_tests.yml` gets both variables rather than just the new
one. It had neither, and it installs a real Opik and drives the SDK
against it, which matches the `installation_type=local` signature the
leaked events carried.

This silences our CI only. Users running Opik in their own CI still
report, since that is real usage worth counting.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…tion

`test_payload_truncation` asserted on warnings via the bare `caplog`
fixture, which captures through the root logger. `opik` sets
`propagate = False` on its root logger at import, so those records never
reach it and `caplog.text` was empty - both tests failed locally on
pytest 9.0.3.

They pass on CI's older resolved pytest, but `pytest` is unpinned in
tests/test_requirements.txt, so this was going to turn into a CI failure
on its own the next time the resolver moved.

`capture_log` is the fixture the suite already provides for exactly this:
it flips propagation on for the test and restores it afterwards. Both
tests now use it, which is also what every other log-asserting test here
does.

The assertions still bite - stubbing out the `LOGGER.warning` call makes
both tests fail, so they are checking the warning rather than passing
vacuously. Full unit suite is now 4502 passed, 0 failed; it was 4500
passed, 2 failed before.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reviewer points, in the order they matter:

- The stats endpoint is now always TLS-verified. It was honouring the
  user's `check_tls_certificate`, but that setting is about reaching
  their own deployment - a self-hosted Opik behind a self-signed cert -
  and comet-stats is a fixed public endpoint. Letting it apply there
  silently weakened a connection the user never pointed at.

- `shutdown` no longer blocks forever on `_LOCK`. It runs from `atexit`,
  and that lock is held while the worker starts, which evaluates rules -
  arbitrary user code. One that blocked would hang the interpreter on the
  way out. It now waits 2s, and switches reporting off either way.

- `end2end_suites_v2.yml` gets the analytics switch. Its sdk-driver
  service runs the SDK outside pytest for the whole suite, so it was
  still reporting CI traffic as a real user's - a hole in the previous
  commit, not a new one.

- `session_properties` loses its `lru_cache`. Both collectors under it
  are already cached, and reporting is once-per-event-per-process, so it
  was caching a bounded dict merge while adding a second thing to reset
  on fork.

Tests, all mutation-checked rather than assumed:

- A public-entrypoint rejection test drives the real composition
  `_start_worker` builds. Removing the `on_rejected` wiring makes it
  fail; nothing else in the suite noticed.
- The worker rejection test asserts the thread actually stops and sends
  nothing afterwards, not just that the callback fired.
- The truncation kwargs test names the field, so logging the wrong one
  cannot pass.
- The fork test drives `environment_details`, which is where the cached
  identity now lives.

Plus the bedrock line wrapped under 88 (the ignore still applies; the
file's other long lines are pre-existing) and a comment typo.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`Sender`'s `httpx.Client` outlived `analytics.shutdown()`. Only its bound
`send` reached the worker, so nothing could close it - verified: the
client was still open after shutdown returned. It is now released on both
paths that end reporting for good, the atexit shutdown and a destination
rejection, and the rejection test asserts it.

Two test fixes from the same review, on tests added earlier today:

- The rejecting collector moves into a `yield` fixture that calls
  `shutdown()`, `server_close()` and joins its thread. Teardown stopped
  at `shutdown()` before, so a failed assertion leaked a listening socket
  and a live thread into every test after it.
- The `@track` semantics test calls the decorated function and checks its
  result. It only applied the decorator before, so a decorator that
  reported the event and returned a broken wrapper would have passed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The first one I introduced two commits ago. Giving `shutdown` a bounded
wait on `_LOCK` fixed a hang, but it also let `shutdown` walk away while
`_start_worker` was still inside `reporting_allowed` - arbitrary user
code, and slow rules are the reason the timeout exists at all. The worker
then published itself on the far side of a completed shutdown.

Reproduced with a rule that sleeps past the timeout: after
`analytics.shutdown()` returned, `_DISABLED` was True but a worker thread
was alive, the connection pool was open, and the in-flight event was
still delivered. `_start_worker` now re-checks `_DISABLED` immediately
before publishing and closes the sender it had already built.

The second: `_track_metric_creation` decided a class was Opik's from
`metric_class.__module__`, which is writable. A subclass setting it to
`opik.anything` - a module that exists, even - had its own class name
reported, and a name the user chose is the one thing these payloads must
never carry. The class is now looked back up in the module it claims.

Both mutation-checked. The shutdown race had no coverage at all, which is
why the earlier hang work did not catch it: that pass asked whether
shutdown could block, never whether it could be undone.

Also checked and not a bug: the claim that a stale `_REPORTING_CODE`
entry suppresses a later independent call. The walk starts above the
reporter, so an unrelated later call to the same method still reports -
verified before changing anything.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`test_review_fixes.py` was named after a review round. Once this merges
that context is gone and the name says nothing about what is covered, so
its tests move to the files that own their subject:

  runtime separator collapsing  -> test_event_names.py
  queue-full claim release      -> test_api.py
  non-string action             -> test_api.py
  rule without __name__         -> test_rules.py
  session properties after fork -> test_fork.py

Two of them had no subject file, so there are two new ones:

  test_lifecycle.py  starting and stopping the machinery - refusing to
                     start with no destination, and not starting after
                     a shutdown has already landed
  test_sender.py     getting events onto the wire - which answers it
                     carries past, which one ends reporting, and TLS

`test_rejection.py` keeps only the reaction to a rejection, its own
subject; the two status tests that decide what counts as one belong with
the sender. The event/sender builders both files were duplicating are now
conftest factories.

Splitting the file surfaced an order dependency that was already there:
the end-to-end rejection test passed in file order and failed alone. It
replaces `OpikConfig` for the whole SDK with a stub carrying only the two
fields `_start_worker` reads, and the worker thread reads it too when
building session properties - `AttributeError: 'C' object has no
attribute 'url_override'`, swallowed, so the event silently vanished. It
only passed because earlier tests had warmed the cache that would have
re-derived it. Both files now override a real config instead. Every file
in the package passes on its own now, which none of this did before.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>