fix(telemetry): drop profile field [skip-runtime-e2e]

[saurabhjain1592]

Summary

Mechanical revert of the v1 telemetry profile field added in 8.0.0 (PR #188). The field was sourced from AXONFLOW_PROFILE, which is already in use by the governance engine on the agent (platform/agent/profile.go:47, ADR-036). A customer setting AXONFLOW_PROFILE=strict for governance would have telemetry POSTs rejected by the server validator with HTTP 400 (validator only accepts dev/prod/unknown).

The field also has no analytics consumer in the platform — deployment_mode (self_hosted | community_saas | unknown) already carries the topology dimension that profile was meant to add. Removing it eliminates the env-var collision class entirely.

Bumps 8.0.0 → 8.0.1. No public API changes. Tracker: axonflow-enterprise#2033.

Why drop instead of rename

grep -rn "Profile\\.S\\|\\.Profile\\b\\|profile.*dimension" platform/ ee/ --include="*.go" | grep -v _test.go returns ZERO hits in non-test, non-checkpoint-service code on the server side. Nothing reads the stored field. No aggregator, no daily-report dimension, no dashboard. Renaming would still cost the 9-repo coordination + a new env var; dropping costs less and loses no analytics signal.

Changes

• axonflow/telemetry.py — remove os.environ.get("AXONFLOW_PROFILE") read, remove profile_env / profile_stripped / profile locals, remove profile key from the payload dict, remove the doc-comment block describing the field.
• tests/test_telemetry.py — remove test_payload_profile_from_env (which monkeypatched AXONFLOW_PROFILE); update test_payload_format to assert "profile" not in payload; update TestSendTelemetryPing::test_payload_posted_correctly similarly.
• axonflow/_version.py, pyproject.toml — 8.0.0 → 8.0.1.
• CHANGELOG.md — new [8.0.1] entry under Removed.

Audit grep result

After the edits:

$ grep -rn 'AXONFLOW_PROFILE' --include='*.py' --include='*.toml' axonflow/ tests/
(no results)

$ grep -rnE '\bprofile\b' --include='*.py' --include='*.toml' axonflow/ tests/
tests/test_telemetry.py:110:        # v1 telemetry-schema field removed in 8.0.1: profile is no longer in payload
tests/test_telemetry.py:111:        assert "profile" not in payload
tests/test_telemetry.py:187:        # 8.0.1: profile field removed (collided with governance env var).
tests/test_telemetry.py:188:        assert "profile" not in payload

Code package + tests are clean of AXONFLOW_PROFILE reads and of profile payload writes. The 4 remaining profile mentions are negation assertions confirming the field is gone. CHANGELOG references in the new 8.0.1 entry + historical 8.0.0 / 6.2.0 entries are intentional.

5-question self-review (per feedback_self_review_is_mandatory_every_pr.md)

For each hunk:

1. Does this hunk do what the commit message claims? Yes — only profile-related additions removed, nothing else from v8.0.0 touched.
2. Are there other call sites I should update too? Per feedback_self_review_check_other_callsites.md, grepped AXONFLOW_PROFILE and \bprofile\b across the repo (see audit above). All references in package code + tests are accounted for.
3. Does the test still test the right thing? test_payload_format and test_payload_posted_correctly now assert "profile" not in payload, which is the actual contract after this PR. The deleted test_payload_profile_from_env was specifically testing the env-var-read behavior we're removing — no replacement needed.
4. Did I leave any debug/dead code? No — verified os import in telemetry.py is still needed by _is_telemetry_enabled, _classify_deployment_mode, and send_telemetry_ping env reads.
5. Will CI pass? Local pytest tests/ is green for all telemetry tests (973 pass, 29 skipped) and for the targeted tests/test_telemetry.py + tests/test_telemetry_short_lived.py subset. Coverage at 81.22% (above the 75% threshold). See "Test plan" below for the one local-only flake noted.

Test plan

• pip install -e ".[dev]" clean
• pytest tests/test_telemetry.py — 23/23 pass
• pytest tests/ — 973 pass, 29 skipped (coverage 81.22%, above 75% threshold)
• CI green on PR

Local-only flake observation (not introduced by this PR)

tests/test_telemetry_short_lived.py::test_telemetry_flushes_on_immediate_exit failed locally on the first run but the cause was a stale ~/Library/Caches/axonflow/python-telemetry-last-sent stamp file gating the heartbeat in the spawned subprocess (the subprocess does NOT inherit pytest's monkeypatched cache dir). Removing the stamp made the test pass. Verified the same failure happens on clean main with the stale stamp — i.e., this is pre-existing test-isolation behavior, not introduced here. Filing a follow-up so the test sets XDG_CACHE_HOME / HOME in the subprocess env to a tmpdir is out of scope for this mechanical revert; CI starts fresh so it doesn't hit this.

No tag

Per feedback_releases_require_approval.md + the issue #2033 brief: do NOT tag v8.0.1 or publish to PyPI on merge of this PR. The full 10-PR train (9 clients + server) needs to merge first; tagging is operator-gated and happens after the train lands.

Coordinated train

This PR is one of nine client-side reverts coordinated under axonflow-enterprise#2033. Server validator removal lands in a parallel axonflow-enterprise PR. Either merge order is safe (JSON unmarshaling tolerates a server still tolerating an absent profile field, and a server tolerating an extra unknown field).

Skip-runtime-e2e justification

This PR is part of the #2033 coordinated train across 1 server + 9 client repos. Per the session-2033 brief, runtime proof is deferred to the post-server-merge staging-checkpoint deploy:

1. axonflow-enterprise#2035 (server) merges + gh workflow run deploy-checkpoint.yml -f environment=staging deploys the new code to staging-checkpoint.getaxonflow.com.
2. Each of the 9 client builds is then driven against staging-checkpoint with verification that (a) POST returns 200 (no validator complaint about missing profile) and (b) the resulting DDB row has no profile attribute.
3. EVIDENCE lands at runtime-e2e/profile_field_removal/EVIDENCE/<utc-ts>/ post-deploy.

Adding a same-PR runtime-e2e/ test here would either:

• exercise a fake checkpoint server (forbidden by lint-no-mocks-in-runtime-e2e.sh), or
• run against the live deployed Lambda BEFORE the server PR has deployed, which would either silently pass (ignored field) or fail (depending on deploy ordering) — neither outcome is informative.

The post-deploy proof against staging-checkpoint is the only meaningful runtime test for this train.