refactor(infra-cdk): migrate to L2 constructs, drop NestedStacks; fix Cedar policy + vite 8 build

[razkenari]

Summary

Recreates the intent of #6 on current main: migrate the CDK infra to L2 constructs
and replace NestedStacks with Constructs. Also fixes two pre-existing, unrelated
bugs that blocked a clean end-to-end deploy.

Infra (infra-cdk/)

• Memory CfnResource → agentcore.Memory (L2)
• Gateway CfnGateway/CfnGatewayTarget → agentcore.Gateway + addLambdaTarget() (L2)
• Move from @aws-cdk/aws-bedrock-agentcore-alpha to stable aws-cdk-lib/aws-bedrockagentcore (graduated in 2.260)
• CognitoStack/BackendStack/AmplifyHostingStack → Constructs (no NestedStacks)
• AgentName CfnParameter → config.yaml (agent_name, typed in AppConfig)
• Dependency bumps to latest; dropped graduated/unused alpha packages (0 npm vulnerabilities)

Fixes (pre-existing, also broken on main)

• Cedar policy: add bedrock-agentcore:InvokeGateway to the policy Lambda role.
  AgentCore's CreatePolicy validation now calls the gateway; without this the policy
  goes CREATE_FAILED ("Insufficient permissions to call gateway"). Confirmed via A/B
  test that main fails identically. Ref: AgentCore policy-permissions docs (Troubleshooting).
• Frontend build: vite.config.ts used the object form of manualChunks, which vite 8
  (rolldown) rejects with "manualChunks is not a function". Converted to the function form
  (same react/ui/auth vendor chunks) and bumped vite to 8.1.0.

Testing

Verified end-to-end on a test account with the standard commands (no flags):

• cdk deploy → CREATE_COMPLETE (incl. Cedar GatewayPolicy)
• python scripts/deploy-frontend.py → Amplify SUCCEED, app loads + login works
• cdk destroy → clean teardown, no orphaned policy engines
• Infra tsc + jest + cdk synth green; frontend npm run build green

[github-actions]

Latest scan for commit: a7b2a0c | Updated: 2026-06-30 03:19:27 UTC

Security Scan Results

Scan Metadata

• Project: ASH
• Scan executed: 2026-06-30T03:19:11+00:00
• ASH version: 3.2.2

Summary

Scanner Results

The table below shows findings by scanner, with status based on severity thresholds and dependencies:

Column Explanations:

Severity Levels (S/C/H/M/L/I):

• Suppressed (S): Security findings that have been explicitly suppressed/ignored and don't affect the scanner's pass/fail status
• Critical (C): The most severe security vulnerabilities requiring immediate remediation (e.g., SQL injection, remote code execution)
• High (H): Serious security vulnerabilities that should be addressed promptly (e.g., authentication bypasses, privilege escalation)
• Medium (M): Moderate security risks that should be addressed in normal development cycles (e.g., weak encryption, input validation issues)
• Low (L): Minor security concerns with limited impact (e.g., information disclosure, weak recommendations)
• Info (I): Informational findings for awareness with minimal security risk (e.g., code quality suggestions, best practice recommendations)

Other Columns:

• Time: Duration taken by each scanner to complete its analysis
• Action: Total number of actionable findings at or above the configured severity threshold that require attention

Scanner Results:

• PASSED: Scanner found no security issues at or above the configured severity threshold - code is clean for this scanner
• FAILED: Scanner found security vulnerabilities at or above the threshold that require attention and remediation
• MISSING: Scanner could not run because required dependencies/tools are not installed or available
• SKIPPED: Scanner was intentionally disabled or excluded from this scan
• ERROR: Scanner encountered an execution error and could not complete successfully

Severity Thresholds (Thresh Column):

• CRITICAL: Only Critical severity findings cause scanner to fail
• HIGH: High and Critical severity findings cause scanner to fail
• MEDIUM (MED): Medium, High, and Critical severity findings cause scanner to fail
• LOW: Low, Medium, High, and Critical severity findings cause scanner to fail
• ALL: Any finding of any severity level causes scanner to fail

Threshold Source: Values in parentheses indicate where the threshold is configured:

• (g) = global: Set in the global_settings section of ASH configuration
• (c) = config: Set in the individual scanner configuration section
• (s) = scanner: Default threshold built into the scanner itself

Statistics calculation:

• All statistics are calculated from the final aggregated SARIF report
• Suppressed findings are counted separately and do not contribute to actionable findings
• Scanner status is determined by comparing actionable findings to the threshold

Scanner	S	C	H	M	L	I	Time	Action	Result	Thresh
bandit	0	0	0	0	0	0	425ms	0	PASSED	MED (g)
cdk-nag	0	0	0	0	0	0	11.9s	0	PASSED	MED (g)
cfn-nag	0	0	0	0	0	0	1.8s	0	PASSED	MED (g)
checkov	0	0	0	0	0	0	5.2s	0	PASSED	MED (g)
detect-secrets	0	0	0	0	0	0	1.1s	0	PASSED	MED (g)
grype	0	0	0	0	0	0	47.3s	0	PASSED	MED (g)
npm-audit	0	0	0	0	0	0	2.2s	0	PASSED	MED (g)
opengrep	12	0	0	0	0	0	19.3s	0	PASSED	MED (g)
semgrep	0	0	0	0	0	0	<1ms	0	MISSING	MED (g)
syft	0	0	0	0	0	0	3.1s	0	PASSED	MED (g)

[brianz]

I tested this on a fresh install, and it works as described. Clean backend and frontend deployments, and also verified the fixes which are present on main.