[codex] Add Docker stack and managed model support

From the PR description

Delivers

• Closes #3 by adding the one-command local Docker stack for frontend, backend, Supabase-compatible auth/rest/postgres, schema bootstrap, and MinIO storage.
• Closes #5 by adding Microsoft Foundry / Azure OpenAI support through the corrected Managed Models architecture rather than a hidden public OpenAI provider remap.
• Partially lays groundwork for #6, but does not close it. Connection validation, local URL warnings, capability probes, and safer local tool defaults remain follow-up work.

Summary

• Add a Docker Compose local stack for frontend, backend, Supabase-compatible auth/rest/postgres, and MinIO storage.
• Add managed model support for user-configured Azure/Foundry and local OpenAI-compatible providers.
• Redesign model settings into Public Models and Managed Models flows, with user-owned endpoint/model/key configuration.
• Route managed models through their own OpenAI-compatible adapter, including streaming and tool-call handling.
• Keep public provider API keys user-owned and avoid hardcoding managed provider secrets.

Root Cause / Context

The local Docker story needed a simple lawyer-friendly stack instead of requiring hosted Supabase/R2 credentials. Separately, Foundry and local LLM support needed to be modeled as user-managed providers because endpoint, deployment/model name, and key vary per installation/admin.

During testing, LM Studio worked from the backend container only through host.docker.internal, and local model tool calling proved unreliable. Issue #6 tracks the follow-up for validation and safer local tool defaults.

Validation

• git diff --check
• npm test in backend (29 tests passing)
• npm run build in backend
• Focused frontend ESLint on touched model/settings files
• NEXT_PUBLIC_SUPABASE_URL=http://localhost:54321 NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY=dummy npm run build in frontend
• Manual browser verification of managed model picker entries and LM Studio plain chat path

Notes

• Public OpenAI models still require a real public OpenAI API key. A Foundry key belongs in the managed Foundry model configuration, not the public OpenAI key slot.
• Local managed models should keep tools disabled unless the selected model proves reliable with OpenAI-style tool calls.