feat(REL-12753): adding agent flag for agent telemetry

[nieblara]

Adds an agent_context property to CLI analytics events that indicates whether the CLI is being used by an agent or a human. Detection checks for known agent environment variables (Cursor, Claude Code, Codex, Devin, Windsurf, Cline, Aider) and TTY status. An explicit LD_CLI_AGENT env var allows unknown agents and skills to self-identify. This is telemetry only. The CLI works identically regardless of detection.

---

Note

Low Risk
Low risk telemetry-only change that adds an extra property to analytics payloads; main risk is misclassification or unexpected init panic if the embedded known_agents.json were malformed.

Overview
Adds automatic agent/CI detection for analytics by introducing DetectAgentContext() (backed by embedded known_agents.json plus TTY checks and an overriding LD_CLI_AGENT env var).

Threads the resulting AgentContext from cmd/root.go into internal/analytics.ClientFn and injects agent_context into all tracked event payloads when non-empty, with new unit tests covering detection precedence and payload inclusion/omission.

^{Written by Cursor Bugbot for commit 3a4f7c7. This will update automatically on new commits. Configure here.}

---

Related Jira issue: REL-12753: Agent vs human usage telemetry

[JackDanger]

Nice work, Ramon — clean abstraction and good test coverage. A few things I'd want to discuss:

1. TTY logic diverges from PR #660
Here in detectAgentContext, "interactive" means either stdin OR stdout is a terminal (OR logic). In #660, isTerminal checks only stdout. So you could have a session where the TTY auto-JSON kicks in but agent detection says "this is a human." These two features should agree on what "interactive" means — or at least the distinction should be documented intentionally.

2. The no-tty label conflates scripting with agent usage
A bash script piping ldcli flags list -o json | jq ... in CI will get labeled no-tty. That's not an agent — it's automation. The telemetry goal from the Confluence doc is to "distinguish agent usage from human usage vs CI/CD automation." This collapses CI/CD and agents into one bucket. Consider splitting: no-tty → automation (or similar) vs keeping no-tty as a catch-all but acknowledging in your analytics that it includes CI/CD.

3. Env var list maintenance burden
The hardcoded knownAgentEnvVars list will need updates as new coding agents emerge (Kiro, Jules, etc). Have you considered reading from a config file or at least adding a comment pointing to a tracking issue so this doesn't silently go stale? The LD_CLI_AGENT escape hatch is great for self-identification, but agents won't set it unless LD's docs tell them to.

4. Minor: envChecker interface could be reused
PR #660 separately checks FORCE_TTY via os.Getenv hardcoded in NewRootCommand. If this envChecker interface were shared, both PRs could inject env vars consistently and avoid os.Setenv in tests (which isn't parallel-safe).

Overall this is solid telemetry-only work with no user-facing behavior change — exactly the right risk profile for the first PR in the stack.

[nieblara]

@JackDanger Will resolve 1 and 4 in the stacked PR!