feat: add Cloud Run support with scale-to-zero

[maxwell-merge-slam]

Summary

• Add HTTP health server (server.ts) for Cloud Run container lifecycle
• Add SIGTERM handler for graceful shutdown
• Multi-stage Dockerfile builds TypeScript in-container (node:20 for livekit-rtc native binary)
• BOT_NAME env var for configuring bot persona on Cloud Run

Test plan

• PORT=8080 node dist/index.js start starts health server and LiveKit worker
• curl localhost:8080 returns 200
• Cloud Run deploy with BOT_NAME=clawd resolves correct config
• SIGTERM triggers graceful shutdown log message

Stack: 2/3 — depends on #8

Generated with Claude Code

[kelvin-bit-brawler]

Code Review — PR #9

Summary: Adds Cloud Run infrastructure: HTTP health server, SIGTERM handler, multi-stage Dockerfile, and BOT_NAME env var support.

Changes reviewed:

• src/server.ts — new minimal HTTP health-check server
• src/index.ts — wires up health server and SIGTERM handler
• Dockerfile — multi-stage build with separate build and runtime stages

Quality Assessment:

Aspect	Status	Notes
Code Quality	pass	Clean, well-documented, minimal footprint
Tests	warning	No tests in the project (pre-existing); health server is simple enough
Security	pass	No secrets exposed; health endpoint returns static "ok"
Performance	pass	Lightweight HTTP server, no overhead concern

Issues found:

1. Dockerfile runtime image size (minor): The runtime stage uses node:20 (~1 GB) while the build stage uses node:20-slim (~200 MB). The PR description says this is intentional for livekit-rtc native binaries, which is a valid reason. However, worth confirming that node:20-slim truly fails at runtime — if it works, switching would cut ~800 MB from the deployed image.

2. SIGTERM handler doesn't close the health server or LiveKit connection: The handler logs and calls process.exit(0), which is fine for Cloud Run's 10-second grace period since Node will forcibly close sockets on exit. But if you ever need a longer drain period (e.g., finishing a chat response in flight), you'd want server.close() and to signal the LiveKit worker to disconnect. Not blocking, just flagging for future consideration.

3. Health server server variable is unused outside startHealthServer: If you later need to close the server (see above), you'd need to return or export it. The current fire-and-forget pattern is fine for now.

Suggestions:

• Consider adding a /.well-known/ready or /healthz route distinction so you can differentiate Cloud Run startup probes from liveness checks in the future. Not needed now, but a common pattern.
• The comment "no-op locally if PORT unset" in index.ts is slightly misleading — the server will start on port 8080 by default even locally (since PORT || "8080" always resolves). If the intent is truly no-op when running locally, you could gate on process.env.PORT being defined. Low priority since it's harmless.

Verdict: APPROVE

Clean, well-scoped PR. The health server is minimal, the SIGTERM handler covers the Cloud Run lifecycle, and the multi-stage Dockerfile is a good pattern. The minor items above are non-blocking suggestions for future iteration.