Feat/document deployment tradeoffs

[AAdewunmi]

Summary

Documents the Render deployment rationale, platform boundary, and production verification path for the StudyBuddy MVP.

Changes

• Added a clear “Why Render” rationale to deployment docs.
• Documented what the app/repo owns versus what Render owns.
• Clarified out-of-scope platform responsibilities like server provisioning, TLS setup, and load balancer management.
• Updated release metadata handling so /health/ can report the deployed Render commit.
• Removed the duplicate /accounts/ auth namespace and kept /users/ as the canonical account route.
• Updated stale verification counts to the current 202 passed baseline.

Behaviour

The project now has clearer deployment documentation and a cleaner URL surface. Render deployment decisions are explicit, and production health metadata can identify the deployed revision.

Why

This makes the deployment approach easier to review, repeat, and reason about. It also keeps the app boundary focused on Django product behaviour while Render handles platform infrastructure.

Validation

• Settings tests passed.
• render.yaml parsed successfully.
• Focused auth and route tests passed.
• Markdown/diff checks passed.
• Confirmed only the regression test references /accounts/.

Result

The repo now documents deployment tradeoffs clearly and removes ambiguity around Render responsibilities, runtime metadata, and auth URL namespaces.

Notes

• Render live route verification still needs to pass; the documented URL previously returned 404 with x-render-routing: no-server.
• DJANGO_SECRET_KEY remains Render-injected and is not committed.
• DATABASE_URL is generated from the managed Render PostgreSQL service.
• /users/ is now the canonical auth route; /accounts/ intentionally returns 404.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!