feat: smart credential detection for multi-agent projects

[aidandaly24]

Description

Implements smart credential detection for multi-agent projects. When adding a new agent with a non-Bedrock model provider:

• Same API key as existing agent → Reuses the project-scoped credential ({projectName}{provider})
• Different API key → Creates an agent-scoped credential ({projectName}{agentName}{provider})

Fixes Issue #148, #162, and #169

Deploy Flow Fixes:

Problem: After destroy and redeploy, credentials weren't being recreated because:

1. Mainline only showed missing credentials in the prompt - if .env.local had the key, it was skipped
2. If provider already existed, mainline returned 'exists' without updating - stale credentials persisted

Solution:

• getAllCredentials() - Shows ALL credentials in prompt, not just missing ones
• Always update provider on deploy - ensures credentials stay in sync with .env.local
• Added updateApiKeyProvider() to update existing providers

Other Fixes:

• getAgentScopedCredentials() - Cleans up agent-scoped credentials on agent removal
• Fixed double-execution bugs in useCdkPreflight and CredentialSourcePrompt

Related Issues

Documentation PR

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:all
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Note: typecheck and lint have pre-existing failures in mainline unrelated to this PR.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	7.21%	468 / 6482
🔵	Statements	6.9%	476 / 6897
🔵	Functions	4.18%	56 / 1338
🔵	Branches	5.06%	189 / 3731

Generated in workflow #169 for commit 78f54fd by the Vitest Coverage Report Action

[aidandaly24]

/strands review this PR. DO NOT MAKE ANY CHANGES TO THE CODE UNDER ANY CIRCUMSTANCES

[agentcore-cli-automation]

Reviewed this PR. Since it's already merged, sharing feedback here for reference:

Already flagged in existing comments (no need to repeat):

• Dead code concern on remove-agent.ts (getAgentScopedCredentials / CREDENTIAL_PROVIDERS are exported but never called — removeAgent() no longer removes credentials). Consider removing both in a follow-up since the credential-preservation-on-removal behavior was adopted.

Minor additional observations (non-blocking, follow-up if desired):

1. CREDENTIAL_PROVIDERS in remove-agent.ts duplicates the non-Bedrock values from the ModelProvider schema (src/schema/constants.ts). If a new provider is added to the schema, this list will silently go out of sync. Since the function is currently unused, this can be cleaned up when/if it's wired in.
2. In resolveCredentialStrategy, the loop iterates existingCredentials without filtering by type === 'ApiKeyCredentialProvider'. It's benign today (non-API-key credentials won't have matching env vars), but would be clearer/safer with an explicit type filter.
3. The deploy flow now calls updateApiKeyProvider unconditionally on every deploy when the provider exists. This is a reasonable design (.env.local as source of truth), but adds an API call per credential per deploy even when nothing changed. Worth monitoring if users report it.

Tests look good — integration tests use real tmp dirs rather than fs mocks, and the unit-test mocking of getEnvVar is appropriate since it's a file-I/O boundary.

No telemetry gap — this change is covered by the existing command-level withCommandRun instrumentation (and no new command was added).

LGTM overall. Nothing here would have blocked merge.