Remove database URL from Lambda environment variables

Easy Mode apps (Task 13447) run with `DATABASE_URL` (with the app's DB password) and `JAAH_ORIGIN_KEY` in their Lambda environment, because the C3 templates (`jaah-ai/easy-template-node`, `-python`) read `DATABASE_URL`. Any apps-account principal allowed `lambda:ListFunctions`/`GetFunctionConfiguration` on `*` — including the account's PowerUser CI role — can read every app's DB password and origin key in one call (`infra/jaah/terraform/apps-hosting/README.md` § Per app records this residual). - Pass the secret's id (`DATABASE_SECRET_ARN`) instead and have both templates read the secret at cold start; give `ea-<env>-runtime` `secretsmanager:GetSecretValue` on only the calling app's `ea/<env>/<slug>/db` (tag-matched or a role per app), and stop `app/hosted_apps/aws.py::ensure_function` writing `DATABASE_URL`. - Until then, deny `lambda:GetFunctionConfiguration`/`ListFunctions` on `function:ea-*` to the apps account's CI role. Out of scope: the provisioning flow's other steps; the CloudFront origin-key design. Done means: - A newly provisioned app's function environment carries no database password (cite `get-function-configuration` keys). - Both templates deploy green and `/api/health` round-trips the DB. - The CI role is denied `GetFunctionConfiguration` on an `ea-dev-*` function (cite the AccessDenied).

App Lambdas get DATABASE_SECRET_ARN instead of DATABASE_URL. Each function reads only its own secret (tag matched to the calling function). Apps CI is denied ListFunctions. Both TF roots applied and verified live on dev. Templates #2 merged, PR #7962 merged; its deploy was superseded by a newer one. Filed draft #13858 (apps account's concurrency quota still 10). Memory: proposed 2.