Build a pydantic-settings config loader with real local/staging/production profiles

Build a configuration system using pydantic-settings for the application below. The goal is one typed Settings object the whole app imports, not os.environ.get(...) calls scattered across a dozen files with inconsistent, silently-wrong string defaults.

APPLICATION
A FastAPI service currently reading DATABASE_URL, API_KEY, and DEBUG via scattered os.environ.get() calls with inconsistent defaults.

REQUIRED SETTINGS
database_url: PostgresDsn, api_key: str (secret), debug: bool, request_timeout_seconds: int, allowed_origins: list[str]

ENVIRONMENTS
local (debug=True, permissive CORS), staging (debug=False, staging DB), production (debug=False, strict CORS, must fail startup if debug is somehow True)

SECRETS HANDLING
api_key and database_url are secrets, injected by the deployment platform as real environment variables in staging/production — never read from a checked-in .env there.

REQUIREMENTS
1. Define a base Settings(BaseSettings) class typing every setting explicitly — no bare str for something that's really an int, a bool, or a URL (use pydantic's AnyUrl or a more specific type where it fits). Use model_config = SettingsConfigDict(env_file=".env", env_file_encoding="utf-8", extra="forbid") so an unrecognized environment variable typo raises loudly instead of silently being ignored.
2. Implement local (debug=True, permissive CORS), staging (debug=False, staging DB), production (debug=False, strict CORS, must fail startup if debug is somehow True) as either a single Settings class with an environment: Literal[...] field driving conditional defaults, or as one subclass per environment — pick whichever fits database_url: PostgresDsn, api_key: str (secret), debug: bool, request_timeout_seconds: int, allowed_origins: list[str] better and say why. Whichever approach, the environment itself must be selected by one explicit variable (e.g. APP_ENV), never inferred from something indirect like "is DEBUG unset."
3. Any setting with no safe default — a database password, an API key, anything in api_key and database_url are secrets, injected by the deployment platform as real environment variables in staging/production — never read from a checked-in .env there. — must be a required field with no default value at all, so the application fails at startup with a clear pydantic ValidationError naming the missing field, rather than starting successfully and failing confusingly the first time that setting is actually used.
4. State the precedence order explicitly and make sure the implementation matches it: real environment variables should override .env file values (this is pydantic-settings' actual default behavior), which should override class-defined defaults — confirm this matches what local (debug=True, permissive CORS), staging (debug=False, staging DB), production (debug=False, strict CORS, must fail startup if debug is somehow True) actually needs for a production deploy where env vars come from the deployment platform, not a checked-in file.
5. Never commit real secret values — provide a .env.example with every required variable name present and a placeholder or empty value, and add .env to .gitignore if it isn't already covered.
6. Add a small validator (@model_validator) for any cross-field consistency local (debug=True, permissive CORS), staging (debug=False, staging DB), production (debug=False, strict CORS, must fail startup if debug is somehow True) implies — e.g. if environment is "production", debug must be False, and say what happens if that combination is ever set: fail startup, don't just log a warning and continue.
7. Give the Settings object a __repr__ or a dedicated logging call at startup that prints every loaded setting except the ones flagged in api_key and database_url are secrets, injected by the deployment platform as real environment variables in staging/production — never read from a checked-in .env there. — an operator restarting the service needs to be able to confirm which environment and config actually loaded without that confirmation ever risking printing a real credential to a log line.

OUTPUT FORMAT
1. The Settings class(es).
2. The .env.example file.
3. One sentence confirming the precedence order and how a missing required secret actually surfaces at startup.
4. Confirmation that the startup log/repr excludes every field flagged as a secret.