fix(config): JCODE_WAKE_MODE is missing from the config-cache fingerprint

Open crates/jcode-base/src/config.rs and inspect CONFIG_ENV_KEYS alongside Config::apply_env_overrides. Run the specified config::tests::config_env_fingerprint_tracks_every_apply_env_override_var regression with the repository's scripts/dev_cargo.sh wrapper; done means JCODE_WAKE_MODE is covered and the existing test passes.

Problem

At 0735c75317e644ecb440e0c3dddb7a6b3cd0d8bf, Config::apply_env_overrides reads JCODE_WAKE_MODE, but CONFIG_ENV_KEYS in crates/jcode-base/src/config.rs does not include it.

ConfigCacheFingerprint::current() uses that allowlist to detect relevant environment changes. Consequently, a change to this variable within the running process does not by itself invalidate the cached configuration. Initial loading with the variable already set still applies the override. This is not a claim that changing a separate shell's environment changes an already-running daemon.

Reproduction

In a clean checkout of the revision above:

scripts/dev_cargo.sh test --offline --locked --profile selfdev \
  -p jcode-base --lib \
  config::tests::config_env_fingerprint_tracks_every_apply_env_override_var \
  -- --exact --test-threads=1

Observed on macOS arm64, Rust 1.100.0-nightly (0dfb098f3 2026-08-31) via the repository's selfdev wrapper:

CONFIG_ENV_KEYS must include every env var read by Config::apply_env_overrides; missing: ["JCODE_WAKE_MODE"]
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 1379 filtered out

Expected: every environment override participates in the fingerprint and the existing completeness regression passes.

Proposed fix and validation

Add "JCODE_WAKE_MODE" to CONFIG_ENV_KEYS. The exact unchanged regression then passes. All 78 existing config::tests:: tests also pass on both the selfdev nightly toolchain and Rust 1.94.1, including wake-mode parsing, runtime-only variable exclusion, and file/save cache invalidation.

The reproduced result is the existing regression. The cache consequence above is traced through the production code, not a live-daemon wake test. No parser, default, API, dependency, or test assertion changes are needed.

Related: #1067 introduced the wake-mode feature and is already closed. This report is specifically about its omission from cache invalidation. Searches for JCODE_WAKE_MODE and fingerprint wake found no existing report of this omission.

Prepared with AI assistance and checked against the source and recorded test results.