feat: add agentcore-cli User-Agent to all API calls

[notgitika]

Summary

Sends agentcore-cli/<version> on all API requests so the service can differentiate CLI vs console vs curl traffic.

• agentcore-control.ts: customUserAgent on all BedrockAgentCoreControlClient instances (deploy, status, list)
• agentcore.ts: customUserAgent on all BedrockAgentCoreClient instances (invoke, evaluate, stop-session)

Test plan

• npm run typecheck passes
• All hooks pass

[jesseturner21]

Base branch mismatch — PR would regress version on preview

This PR targets preview, but the branch contains 7 commits that were merged to main (not preview) plus the actual User-Agent commit:

223b6cd feat: add agentcore-cli User-Agent to all API calls    ← the actual change
933bac8 fix: use pull_request_target for fork PR support (#958)
5271f55 fix: agentcore dev not working in windows (#951)
c30ed54 fix: add TTY detection before TUI fallbacks (#949)
3d2d671 fix: allow code-based evaluators in online eval configs (#947)
cb1e81a fix: buffer streaming text for GH Actions logs (#946)
a365bf5 feat: add GitHub Action for automated PR review (#934)
12275c3 chore: bump version to 0.10.0 (#944)

As a result, the diff against preview is ~1171 lines of changes (most of which have nothing to do with User-Agent), and merging would:

• Downgrade the version from 1.0.0-preview.1 to 0.10.0 (preview is currently at 1.0.0-preview.1, main is at 0.9.1; this PR's package.json says 0.10.0).
• Bring in changes that were only ever reviewed/merged against main, not preview.

Options

1. Retarget this PR to main, which should make the diff shrink to just the two files in src/cli/aws/ (the branch is already based on recent main-equivalent history).
2. Rebase the branch onto preview so only the User-Agent commit remains, then keep the base as preview.

Option 1 is probably the cleanest since the branch already lines up with main.

[jesseturner21]

User-Agent coverage is incomplete

The PR description says:

• agentcore-control.ts: customUserAgent on all BedrockAgentCoreControlClient instances
• agentcore.ts: customUserAgent on all BedrockAgentCoreClient instances

But grep -rn 'new BedrockAgentCore' src/ turns up 8 other client instantiations that were not updated:

src/cli/aws/policy-generation.ts:36          new BedrockAgentCoreControlClient
src/cli/aws/policy-generation.ts:60          new BedrockAgentCoreControlClient
src/cli/operations/memory/list-memory-records.ts:36       new BedrockAgentCoreClient
src/cli/operations/memory/retrieve-memory-records.ts:31   new BedrockAgentCoreClient
src/cli/operations/deploy/pre-deploy-identity.ts:65       new BedrockAgentCoreControlClient
src/cli/operations/deploy/pre-deploy-identity.ts:107      new BedrockAgentCoreControlClient
src/cli/operations/deploy/pre-deploy-identity.ts:298      new BedrockAgentCoreControlClient
src/cli/operations/deploy/gateway-status.ts:32            new BedrockAgentCoreControlClient

These cover real user-invoked API surface (agentcore add policy, memory record listing/retrieval, agentcore deploy identity setup, gateway status polling), so calls from those flows will still look like plain SDK traffic to the service and defeat the goal of distinguishing CLI traffic.

Options

1. Add customUserAgent to each of the 8 missed call sites (straightforward but repetitive).
2. Introduce small factory helpers — e.g. createControlClient(region) / createAgentCoreClient(region) in src/cli/aws/ that set customUserAgent once — and route all callers through them. agentcore-control.ts already has a createControlClient helper; the other files could import it instead of calling new BedrockAgentCoreControlClient directly. This avoids the same gap recurring the next time someone adds a new call site.

[notgitika]

updating the missed call sites using option 2

[Hweinstock]

thanks for updating this to use the shared helper!

[Hweinstock]

not related to this change, but I wonder if we should cache the client for potential connection re-use.