fix(ci): disable telemetry in release workflow to fix test failures

[jariy17]

Summary

• Adds AGENTCORE_TELEMETRY_DISABLED: '1' to the release workflow, matching what build-and-test.yml already sets
• Fixes the 7 unit test failures in the "Update snapshots" step that have been blocking releases

Root Cause

The prepare-release job runs npm run test:update-snapshots (all unit tests, unsharded) without AGENTCORE_TELEMETRY_DISABLED. This causes withCommandRunTelemetry in the TUI hooks (useLogsFlow, useRemoveResource) to trigger real I/O during createClient():

1. getOrCreateInstallationId() → access() + mkdir() + writeFile() to ~/.agentcore/config.json
2. OtelMetricSink construction (network connection attempt)
3. client.flush() in the finally block (actual export attempt)

This I/O doesn't resolve within the 50-100ms setTimeout delays used by the LogsScreen and useRemove tests, so assertions fire while components are still in their loading state.

build-and-test.yml avoids this by setting AGENTCORE_TELEMETRY_DISABLED=1 at the workflow level.

Test plan

• Verified locally: tests pass with AGENTCORE_TELEMETRY_DISABLED=1, fail without it
• Re-run the release workflow after merge to confirm it passes

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[github-actions]

Package Tarball

aws-agentcore-0.16.0.tgz

How to install

gh release download pr-1442-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.16.0.tgz

[agentcore-cli-automation]

Looks good to merge.

The change is minimal, surgical, and brings parity with build-and-test.yml which already sets the same env var at the workflow level. Root cause analysis in the PR description is accurate — withCommandRunTelemetry triggers real fs/network I/O via getOrCreateInstallationId() and OtelMetricSink construction that doesn't resolve within the short setTimeout delays in the affected TUI tests.

One follow-up worth considering (not blocking): the tests really shouldn't depend on a workflow-level env var to avoid hitting the network and writing to ~/.agentcore/config.json. A vitest setupFiles entry that sets AGENTCORE_TELEMETRY_DISABLED=1 (or stubs the telemetry client) would make this immune to the env getting dropped from a future workflow. But unblocking releases now with this CI parity fix is the right call.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	35.47%	10926 / 30803
🔵	Statements	34.8%	11606 / 33341
🔵	Functions	30.12%	1832 / 6082
🔵	Branches	29.38%	6900 / 23483

Generated in workflow #3434 for commit 9239540 by the Vitest Coverage Report Action