Run migrations as an explicit ECS task before deploy

[saqibmanan]

Summary

Phase 3 of the ECS CD-pipeline plan. Stacked on #109 — merge #108 → #109 → this, in order.

Migrations previously only ran inside docker-entrypoint.sh on every container boot — no distinct pass/fail signal in the deploy pipeline itself, and (per the plan) a theoretical race under Fargate's rolling deployment window.

• deploy-to-ecs.yml: bumped aws-actions/amazon-ecs-deploy-task-definition v1 → v2 (checked its changelog — purely additive feature releases since v1, no breaking changes to the inputs already in use) to use its built-in run-task support. Its source confirms the standalone task is awaited and its exit code checked before the service update ever runs — a failed migration now fails the whole deploy job loudly, before any new code ships, instead of being buried in container boot logs nobody's watching.
• New step reads the running service's network configuration (aws ecs describe-services → subnets/security groups/public-IP assignment) rather than hardcoding it or adding new secrets — the migration task always runs in the exact same network context as the real app.
• docker-entrypoint.sh: dropped the now-dead mkdir/chmod/touch migrations-directory scaffolding (only ever needed to support the runtime makemigrations step removed in Fix health-check false-green and unsafe runtime migrations #108).

One deviation from my own plan, worth flagging explicitly: the plan originally said to also remove migrate --noinput from the entrypoint. I didn't — this same Dockerfile/entrypoint is what docker-compose.yml's backend service uses for local dev, and removing it would have silently broken migrations on docker compose up. Left it in as a no-op safety net (migrate is idempotent, so re-running it after the ECS one-off task already applied everything is harmless) with a comment explaining why. The value of the explicit pipeline step — a loud, blocking, pre-deploy failure — doesn't require the entrypoint call to be gone.

Test plan

• Checked amazon-ecs-deploy-task-definition's CHANGELOG.md and compiled index.js source directly (via gh api) to confirm run-task/wait-for-task-stopped waits for the task and calls a real tasksExitCode() check that throws (failing the job) on non-zero exit, and that this happens strictly before updateEcsService()
• actionlint clean on every line this PR touches (pre-existing findings on untouched lines: outdated checkout@v3/configure-aws-credentials@v1, unrelated SC2086 quoting)
• bash -n + shellcheck clean on the entrypoint diff
• Not verifiable locally: the actual describe-services network-config lookup and run-task call against real AWS — no credentials in my environment. This is exactly what Phase 6's staged rollout (build-only first, then one supervised real deploy) is for.