Add APP_NAME environment variable to override the app name

[nopoz]

app.name is currently reachable only through config.yaml, and that file lives inside the application directory, so a container deployment cannot set it without baking in or mounting over a copy of the file. Mounting a copy means re-reconciling it on every upgrade, which is awkward for a setting that is one string.

This adds APP_NAME as an override, following the same shape as the existing variables: env var beats config.yaml, the resolved value is logged with its source at startup, and an empty value is treated as unset the way DEFAULT_THEME already does (a blank name would leave the UI and the login page unlabeled).

INFO:     App name: My Notes (from APP_NAME env var)
INFO:     App name: NoteDiscovery (from config.yaml)

The override runs before the FastAPI app is constructed, so the API docs title picks it up along with everything that reads config['app']['name'] per request.

Also documents the variable in documentation/ENVIRONMENT_VARIABLES.md (Core Settings table plus an example, with the config.yaml equivalent alongside it, matching the existing entries) and notes the override in config.yaml next to the key, as autosave_delay_ms and default_theme already do.

Nothing changes for an existing deployment that does not set the variable.

Testing

Imported the module with the variable unset, set to a name, and set to whitespace only, confirming the resolved name, the log line and its source, and the FastAPI title in each case. With APP_NAME="My Notes", /health reports "app": "My Notes" and the login page renders <title>My Notes</title>, which covers both the request-time consumers and the whole-page replacement.

[gamosoft]

Thanks, merging this, clean work. 😉

Just a few spots still hardcoded the name (PWA manifest, two meta tags, logo alt), I'll fix those separately.

Kind regards