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

[saurabhjain1592]

Summary

The v1 telemetry schema (#169 / commit f27c26b6) added a profile
payload field sourced from AXONFLOW_PROFILE. That env var was already
in use across the platform for governance enforcement (allowlist
dev|default|strict|compliance, see ADR-036 / platform/agent/profile.go).
Meanwhile the v1 telemetry validator only accepts dev|prod|unknown.

The collision matrix:

Customer sets AXONFLOW_PROFILE=	Governance	Telemetry validator
dev	OK	OK
strict	OK	HTTP 400
compliance	OK	HTTP 400
production	rejected	HTTP 400

Any customer setting AXONFLOW_PROFILE=strict or =compliance for
governance enforcement would silently have their telemetry pings rejected
with HTTP 400 from the checkpoint validator.

This patch drops the profile field from the telemetry payload entirely.
The deployment_mode dimension (self_hosted | community_saas | unknown)
already carries the topology signal profile was meant to add, and
AXONFLOW_PROFILE reverts to its single governance-only purpose.

Per #2033 brief, this is the Java leg of a 10-PR coordinated train (server

• 5 SDKs + 4 plugins). No tags will be cut on any repo until the train lands.

Changes

• src/main/java/com/getaxonflow/sdk/telemetry/TelemetryReporter.java —
  remove System.getenv("AXONFLOW_PROFILE") read, the profile payload
  field, and the doc comment block describing the field.
• src/test/java/com/getaxonflow/sdk/telemetry/TelemetryReporterTest.java —
  convert the two assertThat(get("profile")).asText().isEqualTo("unknown")
  assertions to assertThat(has("profile")).isFalse(). Stronger than
  dropping the assertions: actively guards against the field re-appearing.
• pom.xml — version 8.0.0 → 8.0.1.
• examples/explain-decision/pom.xml, examples/list-decisions/pom.xml —
  SDK dep version 8.0.0 → 8.0.1 to keep examples on the latest.
  (examples/basic and examples/wcp-retry-idempotency were already on
  older versions and were left alone.)
• CHANGELOG.md — [8.0.1] entry under Removed.

Self-review audit

Hunk-by-hunk read of git diff complete (5-question protocol per
feedback_self_review_is_mandatory_every_pr.md).

Post-removal grep confirms removal is total:

$ grep -rn 'AXONFLOW_PROFILE' src/
(no matches)

$ grep -rniE '\bprofile\b' src/
src/test/.../TelemetryReporterTest.java:80:    assertThat(root.has("profile")).isFalse();
src/test/.../TelemetryReporterTest.java:167:   assertThat(body.has("profile")).isFalse();

The two remaining profile hits are the absent-field guard assertions —
intentional, the whole point of this PR.

No other Java telemetry callsites reference Profile / profile (verified
across src/main and src/test). The DeploymentMode and EndpointType
nested classes are untouched — those are different concepts (topology /
reachability), not the env-var-collided telemetry profile field.

Test plan

• mvn test — 1236 tests, 0 failures, 0 errors, BUILD SUCCESS
• Runtime proof against staging-checkpoint.getaxonflow.com once
  the server-side leg of the train ships and is deployed to staging
  (per #2033 train coordination).

Refs #2033

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.