fix(gen2-migration): retain GraphQL model tables during decommission

[sai-ray]

Fixes: #14524

Description of changes

Running amplify gen2-migration decommission after migrating an Amplify app with api DynamoDB tables, fails with Validations failed: Decommission will delete stateful resources. The refactor step moves auth, storage, and analytics resources to Gen2 but not GraphQL model tables. Gen2 imports those via modelNameToTableNameMapping. So when decommission tries to delete the Gen1 stack, those tables are still there.

Changes

Lock step (lock.ts):

• Added findApiCategoryStacks(): identifies API nested stacks using startsWith('api') on logical resource IDs from DescribeStackResources.
• Added setDeletionPolicyRetainOnDynamoTables() for each API stack:
  • lists its model nested stacks
  • fetches each template via GetTemplate
  • sets DeletionPolicy: Retain on AWS::DynamoDB::Table resources
  • updates the stack viatryUpdateStack

Validation (_validations.ts):

• In getStatefulResources, when a AWS::DynamoDB::Table is found in a nested stack, fetches the stack template and checks DeletionPolicy. If Retain, skips flagging it. Tables without Retain are still flagged.

By submitting this pull request, I confirm that my contribution is
made under the terms of the Apache 2.0 license.

Issue #, if available

Description of how you validated changes

• Ran the updated lock and decomission commands on a sample Gen1 app.
• Added unit tests.

Checklist

• PR description included
• yarn test passes
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)
• New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
• Pull request labels are added

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[9pace]

For lock --rollback, what do we do? Leave them with the retain policy?

Also, this would modify our deployed cfn template. The proposed rollback validation is running template drift detection which would conflict here. Just flagging for discussion.

[9pace]

Before tryUpdateStack, we should add a changeset validation step similar to what we do in the refactor step.

Right now, setDeletionPolicyRetainOnDynamoTables modifies the template and calls tryUpdateStack directly without verifying that the only changes CloudFormation will apply are DeletionPolicy updates.
for the lock step, we should implement:

 1. Before calling tryUpdateStack, create a changeset on the stack
 2. Describe the changeset and inspect Changes
 3. Validate that every change is a Modify on a AWS::DynamoDB::Table resource, scoped to a deletion policy update that we want
 4. If any unexpected changes are present, abort with a clear error

This is the same pattern as in _validations.ts. See:

amplify-cli/packages/amplify-cli/src/commands/gen2-migration/refactor/workflow/category-refactorer.ts

Lines 147 to 154 in a0015a7

	const report = await this.createChangeSetReport(source);
	return [
	{
	resource: this.resource,
	validate: () => ({
	description: `Ensure no unexpected changes to ${sourceStackName}`,
	run: async () => ({ valid: report === undefined, report }),
	}),