chore(deploy): use Neon Postgres instead of Render's managed database (#377)

[parthrohit22]

Summary

Product decision: deploy PARTHA on Render's web-service tier, but bring Postgres from Neon (free forever) instead of Render's own managed database (its free tier auto-expires after 90 days). This swaps render.yaml's database provisioning and DATABASE_URL wiring accordingly — no application code change needed.

Linked issue

Closes #377

Scope

• Issue or RFC this advances: chore(deploy): use Neon Postgres instead of Render's managed database #377, a direct follow-up to chore(deploy): add Render Blueprint (render.yaml) for partha.uk #340's original Render Blueprint.
• Why this is in scope: an explicit deploy-infrastructure decision from the owner, config-only.
• Accepted evidence it is real: render.yaml parses as valid YAML with the expected structure (checked with yaml.safe_load); no orphaned partha-db/fromDatabase references anywhere in the repo.

What changed

• Removed the databases: block that provisioned Render's own managed partha-db Postgres instance.
• DATABASE_URL is now a manual (sync: false) env var — the same pattern already used for AI_ENCRYPTION_KEY — to be set in the Render dashboard to Neon's connection string once the service exists.
• Updated the file's own top-of-file setup comment: documents the new manual DATABASE_URL step, and notes that app.core.config.Settings.validate_database_url already normalizes a bare postgres:///postgresql:// scheme (exactly what Neon hands back) to postgresql+psycopg:// — so Neon's connection string can be pasted in as-is.

Acceptance criteria completed

• render.yaml no longer provisions a Render-managed Postgres database.
• DATABASE_URL is a manual sync: false env var, documented the same way AI_ENCRYPTION_KEY already is.
• Blueprint still parses as valid YAML with the expected structure.
• The free-tier-vs-persistent-disk conflict stays visible in the comment, not silently resolved.

Testing performed

python3 -c "import yaml, json; print(json.dumps(yaml.safe_load(open('render.yaml')), indent=2))"
→ parses cleanly; structure matches exactly what was intended (single web
  service, envVars including DATABASE_URL: {sync: false}, disk block,
  no top-level databases: key)

grep -rn "partha-db|fromDatabase|databases:" render.yaml
→ no matches (fully removed)

grep -rln "partha-db" docs/ *.md apps/backend/README.md apps/frontend/README.md
→ no matches (nothing else in the repo referenced the Render-managed DB)

No application code, Dockerfile, or other deploy target was touched — this PR is render.yaml only.

Screenshots

Not applicable (infra config only, no UI change).

Security and data considerations

• DATABASE_URL now carries a full external Postgres connection string (including credentials) as a sync: false manual value — never committed to the repo, set directly in Render's dashboard, same handling as the existing AI_ENCRYPTION_KEY secret.
• No change to how the app itself validates or uses DATABASE_URL — Settings.validate_database_url already normalizes any bare postgres:///postgresql:// scheme, which is exactly what Neon (and every other managed Postgres provider) hands back, so this required no code change to support.

Flagging explicitly, not resolved in this PR: this service already has a 5GB persistent disk (for cloned/uploaded repositories), and Render's own current documentation states free web services do not support persistent disks at all. I deliberately did not set plan: free (or any plan) on the web service, since doing so alongside the existing disk would produce a blueprint that either fails to deploy as configured or silently drops durable repository storage. That's a real product tradeoff (pay for a tier that keeps the disk, or accept ephemeral storage on the free tier) for the owner to decide, not something safe for me to default — the file's existing comment already documents this, and I've expanded it slightly for visibility rather than resolving it either way.

Dependencies and blocked work

None.

Scope changes or remaining work

None for this PR's own scope. The web-service plan/tier decision (noted above) remains open and is intentionally out of scope here.

Contributor checklist

• This PR targets dev
• I claimed the issue and had it assigned or acknowledged before starting substantial work
• The branch was created from an up-to-date upstream/dev
• The branch is rebased on the latest upstream/dev
• This PR addresses one clearly scoped issue
• This PR is in scope: it advances a tracked issue (Scope section filled)
• Every acceptance criterion I claim as complete is actually complete
• Relevant tests pass (YAML validity + reference-search checks, per Testing performed)
• Documentation is updated for any user-visible change (the file's own setup comment)
• No secrets, credentials, local env files, or generated artifacts are included
• No unrelated files were changed
• Closing syntax (Closes) is used only because the issue is fully resolved
• Dependencies and follow-up work are linked (none)