Express backend wrapped in serverless-http to run as an ARM64 Lambda container

The refactor separates the Express app definition (app.ts, exported for both local and Lambda use) from the entrypoints - index.ts for local dev and lambda.ts for Lambda. The Lambda entrypoint calls loadSupabaseSecrets() on cold start, which fetches JSON from Secrets Manager and injects the values into process.env so existing createClient() calls in the codebase need no changes.

Auth middleware gains a dual path: in Lambda, it reads userId and userEmail from the API Gateway request context injected by the Lambda Token authorizer (no network call per request). In local dev, it falls back to supabase.auth.getUser(). The storage module similarly branches on AWS_LAMBDA_FUNCTION_NAME to pick S3 with IAM role credentials in Lambda or R2 with explicit credentials locally.

The Lambda handler is wrapped with three Powertools middleware layers: injectLambdaContext (logger), captureLambdaHandler (X-Ray tracer), and logMetrics with cold-start metric capture.

A later commit (c96d725) removes both fallback paths entirely, making auth and storage Lambda-only. This is the right production posture but means local dev needs alternative wiring if you want to test the Lambda code path locally.

This whole container era is superseded - the Lambda later moves to ZIP via NodejsFunction + esbuild (see post 222) and the code physically relocates to infra/lambda/. Read these commits as architecture reference, not as the current state.