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

[saurabhjain1592]

Summary

The v1 telemetry schema (#63) added a profile field sourced from AXONFLOW_PROFILE in scripts/telemetry-ping.sh. But AXONFLOW_PROFILE is already in production use by the agent-side governance enforcement engine (platform/agent/profile.go, allowlist dev | default | strict | compliance, ADR-036). The two namespaces collided:

Customer sets AXONFLOW_PROFILE=	Governance engine	Telemetry validator
dev	accept	accept
strict	accept	reject (HTTP 400)
compliance	accept	reject (HTTP 400)
production	reject	reject (HTTP 400)

A customer running with AXONFLOW_PROFILE=strict (a perfectly normal governance setting) would have had every heartbeat rejected by the checkpoint validator until they unset it, at which point governance would have silently dropped to default.

The field also has no consumer on the analytics side — deployment_mode (self_hosted | community_saas | unknown) already covers the topology dimension profile was meant to add. Dropping the field cleanly resolves the collision and reverts AXONFLOW_PROFILE to its single original meaning (governance only).

Changes

• scripts/telemetry-ping.sh: remove the PROFILE_RAW / PROFILE block reading AXONFLOW_PROFILE; remove --arg profile and the profile: $profile field from the jq payload object.
• tests/heartbeat-real-stack/run_real_stack.sh: remove the matching COLD_PROFILE=$(jq -r '.profile' ...) assertion (no longer in the payload).
• .cursor-plugin/plugin.json: bump version 1.4.0 -> 1.4.1.
• CHANGELOG.md: 1.4.1 entry under Removed.

Self-review (per HARD RULE #1)

Hunk-by-hunk read on every diff. Grep audit before commit:

$ grep -rnE 'AXONFLOW_PROFILE|PROFILE_RAW|"profile":|\.profile\b' . \
    --include='*.sh' --include='*.json' --include='*.ts' --include='*.js' \
    --include='*.yml' --include='*.yaml' \
  | grep -v -E '/(\.git|runtime-e2e/.*EVIDENCE|node_modules)/'

Post-edit: zero hits in scripts/, tests/heartbeat-real-stack/, or workflow files. Remaining hits are CHANGELOG-only (the new 1.4.1 entry describing the removal + the historical 1.4.0 entry which we keep for accuracy).

bash -n clean on both edited shell scripts. JSON-shape smoke-tested with the same jq -n invocation against representative inputs — output is well-formed JSON with the expected fields and no profile.

Coordination

• Refs axonflow-enterprise#2033.
• Three sibling PRs going up in lockstep: claude + codex plugins.
• The 5 SDK repos and the openclaw plugin have the same field-removal but are separate PRs in their respective repos.
• The server-side counterpart removes the validator branch in ee/platform/checkpoint-service/.
• Tag/release intentionally not requested — per session brief, tag of v1.4.1 is operator-gated and waits until the full coordinated train has merged across all repos.

Test plan

• bash -n scripts/telemetry-ping.sh — clean
• bash -n tests/heartbeat-real-stack/run_real_stack.sh — clean
• jq -n smoke-test of the new payload object — produces valid JSON without profile
• Repo-wide grep for AXONFLOW_PROFILE / PROFILE_RAW / "profile": / .profile\b — zero hits in scripts, tests, workflows
• CI green

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.