fix(cli): emit gen2 migration auth Schema override with Required:false

[sarayev]

Problem

During a gen1 to gen2 migration, the generated auth construct did not emit a Schema override for the migrated Cognito UserPool. On the refactor UpdateUserPool against the imported gen1 pool, the construct re-emitted a login-derived standard attribute (for example email) without an AttributeDataType, and the service rejected the update with Invalid AttributeDataType input.

Change

The auth renderer now emits a Schema override for the migrated UserPool. Each existing attribute is emitted with its AttributeDataType, its constraints, and Required: false. That is the one Schema shape that is valid on both the fresh CreateUserPool and the refactor UpdateUserPool against the imported pool:

• an empty Schema array fails CreateUserPool (Schema must have length greater than or equal to 1);
• a member marked Required: true fails the refactor UpdateUserPool (Required custom attributes are not supported), because the service reads any required member on update as introducing a required attribute.

Auto-managed attributes (for example sub, email_verified) and attributes without a data type are dropped, and no override statement is emitted when the pool has no schema.

Scope

Scoped to only this change. The commit is cut on top of #14991, which is reviewed separately.

Testing

• auth.generator.test.ts passes with the regenerated inline snapshots; the migration-app _snapshot.post.generate/amplify/auth/resource.ts fixtures are regenerated to match.
• Validated at local CDK synth: the generated backend compiles clean, with no over-length or data-type-less Schema members.
• e2e validated on a combined branch with fix(cli): filter benign time-relative AppSync ApiKey /Expires drift #14991. The forward migration and refactor complete cleanly: the UserPool create and the refactor update both succeed, with no Invalid AttributeDataType or Required custom attributes errors.

Note

The combined e2e run surfaces a separate, pre-existing failure in the migration rollback path (the Phase 2 amplify push --force that restores the gen1 backend hits Existing schema attributes cannot be modified or deleted on the UserPool). That failure is unrelated to this change: it is in the rollback restore path, not the forward renderer, and a no-fix baseline run fails earlier (at the forward step) and never reaches it. It is being tracked separately.