docs: describe the anonymous weekly usage report in Security

docs/Installation.mdx

@@ -302,6 +302,7 @@ A list of all available environment variables are below. No other env variables
 | LOG_LEVEL            | info            | Overrides the persisted log level for the current container process only. Accepted values are `debug`, `verbose`, `info`, `warn`, `error`, and `fatal`.                                                                                                                                |
 | GITHUB_TOKEN         |                 | GitHub Personal Access Token for higher API rate limits                                                                                                                                                                                                                                |
 | CORS_ALLOWED_ORIGINS |                 | Comma-separated list of origins allowed to call the API cross-origin, e.g. `https://maintainerr.example.com`. Same-origin access (the bundled UI, including via localhost) always works and never needs this; only set it if a separate front end on a different origin calls the API. |
+| TELEMETRY            |                 | Set to `off` to disable the anonymous weekly usage report, whatever the stored setting says. See [Security](./Security.md#how-maintainerr-handles-your-data).                                                                                                                          |
 
 :::tip
 If `BASE_PATH` is set, remember to prefix health-check probe paths accordingly (for example `/maintainerr/api/health/ready`).

docs/Security.md

@@ -23,7 +23,8 @@ Security is expected at the boundary you already control - your LAN, a VPN, or a
 
 Maintainerr is built to keep your data on your own hardware and to be careful with it internally:
 
-- **Everything stays local.** All configuration and state lives in a single SQLite database in your data directory (`/opt/data`). There is no cloud component, no telemetry, and no analytics - Maintainerr never phones home. The only outbound traffic goes to the services you configure (your media server, the \*arrs, Seerr, and so on) and to the metadata providers (TMDB/TVDB) used to match your library.
+- **Your data stays on your hardware.** All configuration and state lives in a single SQLite database in your data directory (`/opt/data`). There is no cloud component holding any of it. Outbound traffic goes to the services you configure (your media server, the \*arrs, Seerr, and so on), to the metadata providers (TMDB/TVDB) used to match your library, and to `telemetry.maintainerr.info` for the weekly usage report below.
+- **The weekly usage report is on unless you turn it off.** Once a week Maintainerr reports how it is running: its version, the platform it runs on, and which media server type is configured. Some weeks it also reports which rule properties, integrations, features, and notification agents are in use, with counts given as ranges rather than exact numbers. The report carries no identifier of any kind and nothing from your library: no account, hostname, URL, API key, library name, or media title, and no IP address is read or stored. Maintainerr asks you once in the web interface after you set up a media server, and you can change the answer at any time under **Settings > About > Help us improve it**. Setting the `TELEMETRY` environment variable to `off` disables it whatever that setting says. The [telemetry collector](https://github.com/Maintainerr/telemetry-collector) is a public repository, and its README lists every field the report can contain.
 - **Outbound connections use verified TLS.** Calls to your services and to metadata providers use HTTPS with normal certificate verification, which the app never disables on its own. Notification email can use TLS and can optionally be PGP-encrypted.
 - **Secrets are kept out of the logs.** Every log line passes through a sanitizer that masks API keys, tokens, `Authorization` headers, and credential-bearing URLs, so secrets do not leak into log files or error dumps.
 - **The rules engine cannot run code or shell out.** Rules are evaluated by a typed comparator, never `eval`-ed. Database access is fully parameterized, so there is no SQL-injection surface, and the server runs no shell commands. Settings you submit are schema-validated before they are saved.