docs: enhance Docker configuration documentation and clarify environment variable usage

[chenyme]

Summary

Clarify Docker deployment configuration loading and override behavior.

This update documents that the Docker image runs from /app, reads /app/config.yaml by default through the compose mount, and uses CONFIG_FILE when a custom container-side config path is needed. It also explains the effective priority order, how docker-compose.full.yml environment variables override config.yaml, and which settings are static infrastructure config versus runtime business settings managed from the admin console.

Change type

• Bug fix
• Feature
• Documentation
• Refactor
• Configuration / deployment
• Security hardening
• Other

Affected areas

• Frontend / UI
• Backend / API
• Authentication / authorization
• Conversations / streaming
• Files / RAG / extraction
• Model routing / providers
• MCP / tools
• Billing / payments
• Admin console
• Deployment / Docker / configuration
• Documentation

Verification

• git diff --check

Screenshots, API examples, or logs

Not included; documentation-only change.

Configuration, migration, and compatibility notes

Configuration changes: Documentation now clarifies Docker config loading from /app/config.yaml, custom path usage through CONFIG_FILE, and the priority order environment variables > config.yaml > built-in defaults.

API changes: None.

Database migrations: None.

Deployment changes: Documentation and compose comments now explain that docker-compose.full.yml sets POSTGRES_DSN, REDIS_ADDR, and REDIS_PASSWORD in environment, which override corresponding values in config.yaml.

Backward compatibility: No runtime behavior changed.

Documentation

• Documentation is not needed for this change.
• Documentation was updated.
• Documentation still needs to be updated.

Security and privacy

• No secrets, tokens, credentials, local config, or personal data are included.
• User data access remains scoped by authenticated user context unless an admin-only path explicitly requires broader access.
• Security-sensitive behavior was reviewed, including authentication, authorization, provider routing, file processing, billing, and admin APIs where relevant.

Checklist

• I searched existing issues and pull requests.
• Changes are focused and do not include unrelated refactors.
• Tests or static verification were run where practical.
• User-facing behavior, deployment steps, API contracts, or configuration changes are documented.
• Generated artifacts are included only when this project explicitly requires them.
• Caches, build output, .pyc files, .env files, and local storage data are not committed.