Let config.toml carry the daemon's environment

[edwin-zvs]

The problem

A credential exported after the daemon started never reaches it. The daemon's environment is fixed at launch, and construct daemon restart re-exec()s the running image (crates/daemon/src/lib.rs), carrying the same environment across — so no number of restarts helps.

The failure is silent and inverted from the user's mental model. Setting DEEPSEEK_API_KEY makes smith work in a fresh shell immediately, while the route pickers stay empty, with nothing on screen to explain why. Found while debugging exactly that: the key was in ~/.zshrc, every hand-run tool could see it, and the one long-lived process that needed it could not.

The change

config.toml doesn't have this problem — it's re-read on every start. This adds [daemon.env]:

[daemon.env]
DEEPSEEK_API_KEY = "sk-..."

layered underneath the real environment. It fills gaps and never overrides, so a machine that exports its keys behaves exactly as before, and an operator can still override a declared value for a single run.

The layer is consulted wherever the daemon resolves a credential — built-in route targets (spec 0179), profiles that name an api_key_env or fall back to a provider's defaults, /configure, and doctor (which loads the same config with no daemon running, so it keeps reporting what the daemon would see, per spec 0168) — and is applied as the base environment of every process the daemon spawns, so a declared credential reaches a harness exactly as an exported one would.

Two deliberate boundaries:

• The floor is applied at spawn, not in the session's env map. That map is persisted as start params; baking credentials into per-session state would leak them to disk and freeze them against a later rotation in config.
• Path overrides and the daemon's own CONSTRUCT_* knobs stay environment-only — they're read while locating the config file, before there is a table to consult. The config comments say so explicitly.

Spec: specs/0180-daemon-environment-from-config.md.

Verification

cargo test --workspace is green (0 failures). Nine new tests cover the precedence rules, blank-value handling, the built-in target appearing from config, a named api_key_env resolving through the layer, and /configure reporting a config-declared key as present.

Also checked live against an isolated daemon whose real environment has no DEEPSEEK_API_KEY, with the key declared only in config.toml:

== daemon env has no DEEPSEEK_API_KEY: <unset>
== router.list_routes:
  route='deepseek' models=['deepseek-v4-pro', 'deepseek-v4-flash'] unavailable=None
  DEEPSEEK PRESENT
== doctor:
  DeepSeek API key       [ok]  DEEPSEEK_API_KEY is set

Negative control — same daemon, declaration removed — reports DEEPSEEK MISSING and [--] DEEPSEEK_API_KEY not set.

No recording: the change has no distinct visual surface (the picker entry it produces already looks the way it looks today).

Relevant binary

Daemon-only change → construct (.claude/worktrees/daemon-env-from-config/target/debug/construct).