feat(telegram): process environment policy, secret values and host hardening

Spec 6 now says this spec adds only the bot token to SecretValues; the speech key and Google client secret are added by the telegram-attachments and google-calendar specs.

docs/telegram-bot.md

@@ -32,6 +32,9 @@ Environment variables, or the `Telegram` section of `appsettings.json` (`Telegra
 | `Telegram:Model` | `claude-code/claude-opus-5-5` | Any `provider/model` the Claude Code provider serves |
 | `Telegram:EditInterval` | `00:00:01.5` | Minimum time between edits of the "Working..." status message |
 | `Telegram:ReconnectInitialDelay` / `ReconnectMaxDelay` | `1 s` / `60 s` | Backoff after lost connection |
+| `PROCESS_ENV_ALLOW` | — | Comma-separated names or globs let through to `bash`, scheduled scripts and MCP servers despite the deny-list (e.g. `GH_TOKEN` for `gh`). Added to `ProcessEnvironment:Allow` |
+| `ProcessEnvironment:Deny` / `ProcessEnvironment:Allow` | built-in deny-list | Added to the defaults (`*_API_KEY`, `*_TOKEN`, `*_SECRET`, `*_PASSWORD`, their `Section__Key` forms and the named provider credentials), never replacing them. Allowing a name that is denied by name stops startup |
+| `ProcessEnvironment:HardenHostProcess` | `true` | Linux: the bot process is made non-dumpable. `ProcessEnvironment__HardenHostProcess=false` for a debugging session only |
 
 Sessions are stored as usual under `~/.volcanic/agent/sessions/telegram-<chatId>/`; after a restart each chat resumes
 its most recent conversation.
@@ -82,6 +85,33 @@ The agent has the built-in tools, including `bash`, and runs them as the bot's O
 are served (everyone else is ignored and logged), and only in private chats. Run the bot as a dedicated user or in a
 container, and treat the workspace root as writable by anyone on the allow-list.
 
+Secrets are removed from the environment of `bash`, scheduled scripts and MCP servers: every variable on the deny-list
+(see `ProcessEnvironment:Deny` above) is dropped, and so is any variable whose value is the bot token, whatever its
+name (a Coolify alias, for example). `PROCESS_ENV_ALLOW` lets a named variable through, for example `GH_TOKEN` so the
+agent can use `gh`. At startup the bot logs which rules apply, names only:
+`Process environment: 15 deny rules, allow: GH_TOKEN`.
+
+On Linux the bot's own environment can't be read through `/proc/<pid>/environ` or ptrace: at startup the process
+makes itself non-dumpable (`prctl(PR_SET_DUMPABLE, 0)`). Set `DOTNET_EnableDiagnostics=0` in the bot's environment
+too (a container image should set it): otherwise the .NET diagnostic socket still hands the environment to any process
+of the same user, and the bot logs a warning saying so.
+
+The bot token and the other configured secrets are replaced by `[REDACTED]` in tool output, so the model never sees
+them in a tool result, whichever file or process they were read from. Encoded forms (base64, URL-encoded, split
+across lines) aren't matched.
+
+`ProcessEnvironment:HardenHostProcess=false` (`ProcessEnvironment__HardenHostProcess=false` in the environment),
+together with unsetting `DOTNET_EnableDiagnostics`, turns the hardening off for a debugging session. While it is on:
+
+- the bot writes no core dumps, including .NET's own `createdump` on a crash;
+- `/proc/<pid>/*` of the bot is owned by root, so tools that read it for that pid (such as `lsof -p`) see less;
+- `dotnet-dump`, `dotnet-trace`, `dotnet-counters` and debuggers can't attach.
+
+The agent's own processes are unaffected. Turn it back on once you're done.
+
+This is not a sandbox. The agent still runs as the bot's user and can read the agent dir, session transcripts and any
+file that user can read. The container is the isolation boundary.
+
 ## Connection loss
 
 Polling uses Telegram.Bot's built-in loop with a hardened error handler: