Gen 2 migration Subtask 2: Cut alpha over to Gen 2 (table import + function cutover + CI/CD)

Story Points: 8

# How?

Part of #292 (Amplify Gen 1 → Gen 2 Rebuild). Full detail in `.claude/plans/can-you-make-a-shimmying-crane.md`, sections 5–7 and Phase 5. Depends on the Phase 4 sub-issue (all 10 Lambdas built and sandbox-validated) being done first.

Cut the live `alpha` environment over from Gen 1 to Gen 2 without data loss or downtime:

1. **DynamoDB backups**: `aws dynamodb create-backup` on all 7 live tables — cheap, instant, explicit rollback point before any risky operation.
2. **Table import**: `cdk import` the 7 live tables into the new Gen 2 stack (brings existing physical tables under Gen 2 management without delete/recreate, as long as the new stack's table definitions match closely enough for CFN to accept the import). Fallback if import rejects any table's properties: blue/green with a scripted export/import to new tables (more work, cleaner rollback, brief write-pause window).
3. **Function cutover**: deploy the 10 Gen 2 Lambda constructs into the same stack, referencing the now-adopted tables. Name to match Gen 1's `-alpha` convention where feasible to minimize downstream churn (integration test's `ENV_SUFFIX`).
4. **CI/CD adaptation**:
- `backend-ci.yml`: stays infra-agnostic; optionally add a `cdk synth`-only step to catch CDK errors pre-merge without needing AWS credentials in PR builds.
- `backend-cd.yml`: drop the Amplify-CLI config-file dance (`amplify env pull`) for plain AWS credential env vars; replace `amplify push --yes` with `npx ampx pipeline-deploy --branch alpha --app-id `. Requires provisioning a Gen 2 Amplify app resource first to get the app ID.
- `backend-canary.yml`: same credential simplification; fetch `amplify_outputs.json` via `ampx generate outputs --branch alpha --app-id ` in place of `amplify env pull`.
5. **Integration test rewrite** (`amplify/ts-code/__tests__/integration/Amplify.test.ts`):
- Config source swaps from `aws-exports.js` to Gen 2's `amplify_outputs.json` (different shape — nested `auth.user_pool_id` vs. flat `aws_user_pools_id`).
- The direct-Lambda-invoke pattern (sign in → Identity Pool credentials → invoke by name) needs a real rewrite since the fresh Cognito pool has no existing users — add a sign-up/fixture-user-creation step before the existing sign-in call. Update `ENV_SUFFIX`/function name assumptions to match Gen 2 naming.
6. **Bake period**: at least 1–2 weeks with the canary workflow green against the new stack before proceeding to decommission (next sub-issue).

Verification: `describe-table` post-`cdk import` to confirm zero data change; a real test SMS through smsrouter; canary workflow green for the full bake period.

Note: no AWS CLI access in the Claude Code environment used to draft this plan — any step needing live AWS console/CLI verification (`cdk import` execution, post-cutover `describe-table` diffs) needs to be run and reported back by a human with AWS credentials configured.

El plan está en .claude/plans/can-you-make-a-shimmying-crane.md, en las secciones 5–7 y la Fase 5. Empieza verificando que la dependencia de la Fase 4 (10 Lambdas compiladas) esté completa. El trabajo incluye operaciones de AWS CLI (cdk import, dynamodb backup), actualizaciones de los archivos de CI/CD (backend-cd.yml, backend-canary.yml) y reescribir la prueba de integración Amplify.test.ts para usar amplify_outputs.json. «Hecho» significa que el entorno alpha se ejecuta en Gen 2 sin pérdida de datos y que el flujo de trabajo canary se mantiene en verde durante 1–2 semanas.

Escrito por el modelo de indexación a partir del texto del issue.