Add AI agent detection to user-agent header

[simonfaltum]

Summary

Adds detection for 15 AI coding agents (amp, antigravity, augment, claude-code, cline, codex, copilot-cli, copilot-vscode, cursor, gemini-cli, goose, kiro, openclaw, opencode, windsurf) so the SDK emits a single agent/<name> segment in its user-agent string when an agent is identified. Mirrors parallel work in the Go (databricks/databricks-sdk-go#1637), Java (databricks/databricks-sdk-java#768), and Python (databricks/databricks-sdk-py#1394) SDKs so all four SDKs ship the same canonical list and precedence rules.

Why

Databricks wants visibility into which AI coding agents are calling our APIs so that we can understand adoption, prioritize fixes for the environments our customers use, and detect compatibility issues early. The three sibling SDKs just landed this feature; the JS SDK has a smaller detection list (9 agents), emits one segment per detected agent instead of a single canonical segment, and does not honor the AGENT=<name> standard from agents.md. Without this change, traffic from JS SDK users running inside agents is invisible or reported inconsistently with the other SDKs.

The library policy in .agent/rules/libraries.mdc prefers picking a dependency over hand-rolling. We intentionally deviate here: the canonical agent list, env var names, and precedence rules are coordinated across four SDKs, and existing libraries (std-env, @vercel/detect-agent) cover different subsets of agents, apply different precedence, and would re-introduce drift the moment we add a new agent. Implementation is ~80 lines with zero dependencies and matches the Go/Java/Python implementations.

What changed

Interface changes

• packages/core/src/clientinfo/agent.ts (new) - Exports agentProvider() (cached for the process lifetime) and lookupAgentProvider() (uncached, primarily for tests). clearAgentCache() is exported from the module file (not the barrel) for tests only, matching the pattern documented in .agent/rules/testing.mdc for intentionally-unbarreled symbols.
• packages/core/src/clientinfo/index.ts - Adds agentProvider to the public barrel.

Behavioral changes

• createDefault() now appends at most one agent/<name> segment instead of one per matching env var. When two explicit matchers fire simultaneously (ambiguity), no agent/ segment is emitted.
• AGENT=<name> is now honored as a fallback. When no explicit env var matches, AGENT=<known-product> maps to that product, any other non-empty AGENT value maps to agent/unknown, and an empty or unset AGENT emits nothing.
• Explicit env vars always win over AGENT=<name> (e.g. CLAUDECODE=1 + AGENT=goose reports claude-code).
• Detection is cached for the process lifetime, matching Go's sync.Once, Java's volatile lazy init, and Python's _agent_provider sentinel.
• Agent list grows from 9 to 15: adds amp, augment, copilot-vscode, goose, kiro, windsurf. Existing nine agents continue to work.

Internal changes

• The inlined KNOWN_AGENTS list and detectAgents() function in packages/core/src/clientinfo/default.ts move to the new module.
• The existing default.test.ts test case multiple agents all reported is replaced by multiple agents are ambiguous and omit the agent segment to reflect the new ambiguity semantics. Two new cases cover the AGENT fallback path. Adds clearAgentCache() calls in beforeEach/afterEach since detection is now cached.
• packages/core/vitest.config.browser.ts excludes tests/clientinfo/agent.test.ts for the same reason default.test.ts is excluded: agent detection reads process.env and is Node-only.

How is this tested?

• New packages/core/tests/clientinfo/agent.test.ts mirrors the Go test cases from useragent/agent_test.go: every agent detected via its primary env var, empty-string env values counting as set, ambiguity when two explicit matchers fire, AGENT fallback for known and unknown values, explicit env vars winning over AGENT=<name>, the pinned COPILOT_CLI + COPILOT_MODEL ambiguity case for Copilot CLI BYOK users, and cache persistence after env changes.
• npm run format:check, npm run lint, npm run typecheck, npm test, and npm run test:browser all pass. Core package runs 240 unit tests (29 new) and 150 browser tests.

[parthban-db]

LGTM modulo comment.

[parthban-db]

Why do we expose this? I don't think users need to access it.