feat: tag CLI requests with the command that made them

[PaulAsjes]

Nothing on the backend can currently tell that a request came from the CLI, let alone which product it belongs to. request_log.py identifies clients by X-Fern-SDK-Name; the CLI's entire header set is accept, accept-encoding, authorization, host, user-agent.

path_pattern is already logged, so once CLI traffic is identifiable most products fall out of the path. The one thing paths cannot express is agents-as-code: agents push and agents create hit the same convai endpoints. This adds that missing dimension.

Each workflow handler opens a CommandScope, which appends cmd/<command> to the User-Agent for the duration of the command:

User-Agent: elevenlabs-cli/1.0.0 cmd/agents.push

Pairs with the backend change in xi (feat/log-cli-traffic), which parses this into client_kind, sdk_name, sdk_version and cli_command.

Why the User-Agent and not a header

RequestOptions.additional_headers never reaches the wire. HttpClient::send_request only calls apply_custom_headers on its non-executor branch, and this CLI always uses the executor:

if let Some(executor) = &self.executor {
    executor.execute(req).await          // no apply_custom_headers
} else {
    self.apply_custom_headers(&mut req, options)?;
    ...
}

That is also why the X-Source: agents-cli we already set is silently dropped — and why v0's attribution via is_agents_cli_x_source (xi_shared_workspace/generation_attribution.py:144, constants.py:43) stopped firing on v1. Worth reporting upstream alongside the parse_response status-check fix they shipped in 0.38.0, since it is the same structural gap.

Tags are static, never derived from argv

crate::cli_args::extract_subcommand_path is public and would have been convenient, but it returns positional tokens — agents test my-agent would put the agent's name in the User-Agent and from there into request logs. Every tag here is a static string chosen per handler, and the &'static str signature enforces it.

Verified on the wire

agents pull                       ->  elevenlabs-cli/1.0.0 cmd/agents.pull
tools pull                        ->  elevenlabs-cli/1.0.0 cmd/tools.pull
models list (generated)           ->  elevenlabs-cli/1.0.0
ELEVENLABS_VIA=envtoken/2.0 ...   ->  elevenlabs-cli/1.0.0 envtoken/2.0 cmd/agents.pull
--via partner/9.9                 ->  elevenlabs-cli/1.0.0 partner/9.9

Plus a leak check: agents test "my secret agent name" puts nothing user-supplied in any User-Agent.

The last row is a deliberate gap. --via sets an override that beats the env var wholesale, so an explicit --via drops our tag. Losing telemetry is the right side to fail on versus clobbering a consumer's own token — but it means --via users are invisible in the command dimension. Closing that needs framework support for composing the two.

Scope

Covers the 15 hand-written workflow handlers, which is exactly the set path_pattern cannot distinguish. Generated commands (TTS, dubbing, …) are already product-identifiable from the path. Command-level data for those needs Fern to emit it at dispatch, where op_path is known.

Tests

4 new unit tests covering the tag format, append-not-clobber, restore-on-drop, and that the env key tracks the configured flag name (so a userAgentSuffixFlag rename upstream cannot silently detach this). Full suite green: 1903 + 68 + 2 + 755 + doc.

All changes are under cli/elevenlabs/workflow/, which is fernignored.