fix: set iamRoleFallback to true for lambda gateway targets

[tejaskash]

Summary

• Syncs TARGET_TYPE_AUTH_CONFIG with @aws/agentcore-cdk — sets iamRoleFallback: true for the lambda target type, matching lambdaFunctionArn.
• Without this, the CLI's auth config would disagree with the CDK constructs on whether lambda targets use IAM role fallback.

Closes #1005

Companion CDK PR: https://github.com/aws/agentcore-l3-cdk-constructs/pull/197

Test plan

• Existing tests pass — schema change only affects CDK synthesis behavior (handled by CDK PR)
• Merge CDK PR first, then this one

[agentcore-cli-automation]

Thanks for the fix — the schema sync is correct and the lambda target type logically belongs in the iamRoleFallback: true group alongside apiGateway / lambdaFunctionArn.

One concern about the rollout, though: the actual user-facing fix (the one from issue #1005) lives in the CDK synthesizer — Gateway.ts currently passes credentialProviderConfigurations straight through from buildCredentialConfig(target) in the Lambda-compute branch (around line 537) without applying the authConfig.iamRoleFallback branch that's used for openApi/smithy (line 443) and apiGateway (line 323). The CLI schema change in this PR is a no-op on its own — iamRoleFallback is never read inside the CLI, only by the CDK at synth time.

src/assets/cdk/package.json pins "@aws/agentcore-cdk": "^0.1.0-alpha.19". If this PR merges and a new CLI version is published without bumping that pin to whatever version ships the companion CDK fix, users running agentcore create will still resolve the old CDK from npm and agentcore deploy will continue to fail with CredentialProviderConfigurations is required for Lambda targets.

A couple of options:

1. Bump the @aws/agentcore-cdk version range in src/assets/cdk/package.json in this PR (or a stacked follow-up) to require the minimum version that contains the companion fix, and land them together.
2. Merge this PR but block the next CLI release until the CDK version bump PR lands, with a note on the release checklist.

Option 1 is safer since it makes the coordination explicit in the repo rather than relying on release discipline.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	42.89%	8936 / 20830
🔵	Statements	42.17%	9485 / 22491
🔵	Functions	39.66%	1537 / 3875
🔵	Branches	39.82%	5769 / 14486

Generated in workflow #2308 for commit 10c1a6d by the Vitest Coverage Report Action