Add attribution of CLI harness/source when spawning the Elastic CLI

### Summary

Currently, our telemetry and reporting mechanisms only capture user-agent (`UA`) and custom HTTP header (`x-elastic-client-meta`) information, which attributes all invocations to `elastic-cli` regardless of which agent or external harness (e.g., Claude, Cursor, Ramen, Opencode) spawned the CLI process. This results in a loss of visibility and proper attribution in BI and telemetry reporting.

### Problem
When the CLI is invoked by external tools, the headers are overwritten by the CLI, making all requests appear as if invoked directly by `elastic-cli`.

### Proposed Solution
- Investigate if CLI invocations can detect and attribute their harness/source (such as Cursor, Claude, Ramen, Opencode, etc).
- Potential approach: Examine specific environment variables (e.g., `CURSOR_AGENT`, `CLAUDECODE`) or use CLI flags to infer and annotate the source of the invocation.
- Ensure this information is captured in the telemetry data sent by the CLI (including UA and/or `x-elastic-client-meta`).
- Consider how similar attribution can be handled on the Kibana API side if applicable.

### Acceptance Criteria
- [ ] CLI can detect and distinguish which harness/agent spawned it, when possible.
- [ ] Attribution information is sent via telemetry (UA, custom headers, etc).
- [ ] Documentation describes how attributions are determined and examples for known agents/harnesses.

### Context
Attribution is crucial for unified skills, telemetry, and BI reporting. See internal discussion for more details.

[View original Slack conversation](https://elastic.slack.com/archives/C0AHBHPJPHU/p1779123723201589?thread_ts=1779123723.201589&cid=C0AHBHPJPHU)