feat(gateway-target): allow API_KEY outbound auth on mcpServer / smithyModel / lambda targets

[aidandaly24]

Description

The user ask is "API Key — credential". The CLI already supports adding an ApiKeyCredentialProvider via agentcore add credential (CredentialPrimitive.tsx), and AWS::BedrockAgentCore::ApiKeyCredentialProvider is fully supported in CFN (docs). The actual gap is where API_KEY is allowed as outbound auth on a Gateway Target.

Today, in src/schema/schemas/mcp.ts:53–63, the OUTBOUND_AUTH_BY_TARGET_TYPE map permits API_KEY only on openApiSchema and apiGateway targets:

openApiSchema: { authRequired: true,  validAuthTypes: ['OAUTH', 'API_KEY'], iamRoleFallback: false },
apiGateway:    { authRequired: false, validAuthTypes: ['API_KEY', 'NONE'], iamRoleFallback: true  },
mcpServer:     { authRequired: false, validAuthTypes: ['OAUTH', 'NONE'],   iamRoleFallback: false },
smithyModel:   { authRequired: false, validAuthTypes: ['OAUTH'],           iamRoleFallback: true  },
lambda:        { authRequired: false, validAuthTypes: ['OAUTH', 'NONE'],   iamRoleFallback: true  },
lambdaFunctionArn:{ authRequired:false, validAuthTypes: ['OAUTH', 'NONE'], iamRoleFallback: true  },

Customers integrating third-party MCP servers (most common case: mcpServer target type pointing at a public HTTPS MCP service) almost always need API key auth — but the schema rejects it today. CFN itself does not constrain this — the ApiKeyCredentialProvider's resulting credential ARN can be wired into any target's credentialProviderConfigurations.

Acceptance Criteria

• Extend OUTBOUND_AUTH_BY_TARGET_TYPE to allow API_KEY on mcpServer, smithyModel, lambda, and lambdaFunctionArn (or whichever subset the service supports — verify with the service team).
• L3 construct (@aws/agentcore-cdk — src/cdk/constructs/components/mcp/Gateway.ts:270–282) already builds the apiKeyCredentialProvider block; confirm it's wired for all target types and not just apiGateway/openApiSchema.
• Add an --api-key-header-name / --api-key-location flag pair (optional, defaults: HEADER / x-api-key) so users can override where the API key is injected.
• Update CLI validation in src/cli/commands/add/validate.ts:464 to permit the wider target-type set.
• Snapshot tests updated for the new combinations.

Additional Context

• CFN support: YES — ApiKeyCredentialProvider resource is fully supported, and credentialProviderConfigurations on GatewayTarget accepts API_KEY for any target type the service allows.
• CLI gap: schema-level constraint, not L3-level — this is the cleanest fix in the CLI repo.
• L3 partial: today Gateway.ts:270–282 hardcodes credentialLocation: 'HEADER' and credentialParameterName: 'x-api-key' — should accept overrides.
• See companion issue: token-exchange (fix: improve TUI initial screen based on project state #10) for the OAuth side of the same outbound-auth surface.