fix(devops): render.yaml deployment config is stale/non-functional

[Srejoye]

Closes #636

Problem

render.yaml was a leftover/copy-pasted template from a different (Mongo-based) project, never updated to match this repo's actual FastAPI/Postgres/Celery architecture:

• startCommand: gunicorn app:app ... — no app.py/app:app import target exists anywhere in the repo. The real FastAPI instance is app.main:app (confirmed by Dockerfile line 84).
• buildCommand: pip install -r requirements.txt — runs from repo root, but the only requirements.txt lives at backend/requirements.txt.
• envVars included MONGO_URI, unreferenced anywhere in backend/app/config.py (the app uses DATABASE_URL for SQLAlchemy/Postgres), and ENCRYPTION_KEY, which doesn't match the real FIELD_ENCRYPTION_KEY setting.
• Genuinely required production vars (DATABASE_URL, CELERY_BROKER_URL/CELERY_RESULT_BACKEND, JWT_ALGORITHM, CHROMA_PERSIST_DIR, UPLOAD_DIR, GRAPH_PERSIST_DIR) were absent.

A deploy from this file as-is would fail at build (missing requirements.txt) or, if worked around, fail at boot (gunicorn unable to locate app:app).

Fix

• buildCommand now installs from backend/requirements.txt.
• startCommand now runs cd backend && gunicorn app.main:app --bind 0.0.0.0:$PORT --workers 2 -k uvicorn.workers.UvicornWorker — correct entrypoint, correct working directory (Render's runtime: python builds/runs from repo root, so backend/ needs to become cwd for app.main to resolve), and the uvicorn worker class gunicorn needs to serve an ASGI app.
• Replaced MONGO_URI/ENCRYPTION_KEY with the actual vars referenced in Settings (config.py): DATABASE_URL, CELERY_BROKER_URL, CELERY_RESULT_BACKEND, JWT_ALGORITHM, CHROMA_PERSIST_DIR, UPLOAD_DIR, GRAPH_PERSIST_DIR, plus FIELD_ENCRYPTION_KEY (auto-generated, same as SECRET_KEY) and ENVIRONMENT=production so validate_production() actually enforces the secrets it's meant to.
• Corrected PYTHON_VERSION from the stale 3.10.12 to 3.11.9, matching the Dockerfile's pinned python:3.11-slim base.
• Considered rootDir: backend instead, but that would break buildCommand's reference to backend/requirements.txt becoming backend/backend/requirements.txt; explicit backend/-relative paths plus a cd backend in startCommand is more correct than aliasing the whole service root.

CI safeguard

Since this is a config file, no unit test applies. Added a new render-config-smoke-test job to .github/workflows/ci.yml that:

1. Parses render.yaml directly (not a copy/re-derivation of the commands).
2. Runs its buildCommand verbatim.
3. Runs its startCommand verbatim and polls /api/health for up to 30s.

This makes deploy-config drift like this fail CI on every PR, instead of failing silently only on an actual Render deploy.

GSSoC'26

[param20h]

fix issues