[P1] A long-lived helper freezes config and rebuilds the wrong --preset image

Azathothas

Tested the published **wsl-toolkit-v1.3.0 Windows amd64** binary on Windows 11/WSL2 on 2026-09-10. SHA-256: `71b2ef9b0cf50da0acda45e7cc9293185a2b18d8aa403812e20ed29222d54424`, matching the release manifest. Related: #6 and #7. ## Summary A detached helper freezes the config and runner state from startup. Later config edits are interpreted differently by `run`, `matrix`, and `base`; most seriously, `base ensure --preset ...` can announce one image while the helper rebuilds another. ## Reproduction 1: catalog inconsistency 1. Start a helper with a custom catalog containing only `mini`. 2. Edit the same `config.json` to add image id `bad` with a deliberately unavailable fully qualified tag. 3. Without restarting the helper: ```powershell & $wtk run --image bad --json -c 'echo must-not-run' & $wtk matrix --images bad --json -c 'echo must-not-run' ``` Observed: `run` resolves `bad` client-side, sends its full reference, and reaches the expected registry failure. `matrix` sends only the id; the helper rejects it as not in the startup catalog and says only `mini` is available. Restarting the helper makes the same matrix command resolve `bad` and produce an unreached row. ## Reproduction 2: preset builds the wrong base With the main helper started while the saved base image was Arch: ```powershell & $wtk base ensure --preset docker.io/library/alpine:latest & $wtk base ensure --preset alpine --save & $wtk base status --probe --json & $wtk base shell --root # inspect /etc/os-release and podman --version ``` Observed: the client announced the Alpine selection/rebuild and `--save` updated config to Alpine, but the helper rebuilt Arch from its startup config. Status/config then disagreed with the actual distro; `/etc/os-release` was Arch and Podman was 6.1.1. ## Cause `NewHelperServer(cfg, ...)` creates one `Runner` and stores `cfg` for the helper lifetime. The base ensure request contains only `{force}`. The client applies/saves the preset locally but sends neither the selected base config nor image to the helper. Matrix similarly sends image ids for the helper's stale catalog to resolve; single run sends a resolved reference. ## Expected Commands routed through a long-lived helper must use the same effective config the invoking client just validated. Preset selection must reach the helper and rebuild the selected image, and `run`/`matrix` must resolve catalog entries consistently. Add acceptance cases that edit config after helper startup and that verify the actual `/etc/os-release` after helper-routed preset switches.

Azathothas

Fixed in `wsl-toolkit-v2.0.0`, by `WSL-44` in `TODO/wsl-toolkit-go.md`. A long-lived helper no longer freezes what it read at startup. It re-reads the configuration per request, reports the fingerprint it is serving, and `helper status` says whether that is the same configuration the client holds, so a caller can see a disagreement rather than discover it through a rebuilt image. Covered by the acceptance suite against a real machine, which is green at 69 of 69 on 2026-09-10: ```text ok helper status says whose configuration the helper is running ``` That case asserts `config_fingerprint`, `client_config_fingerprint` and `config_matches_client` together, so a helper serving a stale catalog is a reported disagreement rather than a silent one.