## Summary When a GitLab Duo agent uses `glab` to perform actions (for example, creating an MR, posting a comment, or updating an issue), there is currently no way to associate that CLI invocation with the originating agent session. This makes it impossible to trace which agent session triggered a given API action. ## Proposal Support a `GITLAB_DUO_SESSION_ID` environment variable on the root command. When set, its value is forwarded as an `X-Gitlab-Duo-Session-Id` HTTP header on every API request made during that invocation. ### Behavior - Environment variable: `GITLAB_DUO_SESSION_ID` - Type: `string` - Scope: global (available to all subcommands) - When set, inject the value as a custom request header: `X-Gitlab-Duo-Session-Id: <value>` ### Implementation notes The existing `customHeaders` mechanism in `internal/api/client.go` already supports injecting arbitrary headers via `WithCustomHeaders`. The implementation should: 1. Read the `GITLAB_DUO_SESSION_ID` environment variable in `internal/cmdutils/repo_override.go` or a new `duo_session.go` alongside it, following the same pattern as other global env var overrides. 2. In `PersistentPreRunE`, read the env value and, if non-empty, append `X-Gitlab-Duo-Session-Id` to the custom headers passed to the API client. 3. Propagate the header through the `Factory`/`ApiClient` so it is included in every outgoing request for the lifetime of the command. ### Example usage ```shell # Via environment variable GITLAB_DUO_SESSION_ID="duo-session-abc123" glab mr create --fill GITLAB_DUO_SESSION_ID="duo-session-abc123" glab issue create -t "Fix bug" ``` ## Acceptance criteria - [ ] `GITLAB_DUO_SESSION_ID` env var is read at startup - [ ] When set, `X-Gitlab-Duo-Session-Id` header is present on all outgoing API requests - [ ] Unit tests cover env var reading and header injection - [ ] No impact on existing behavior when the env var is not set