fix(config): skip a rejected env override in every command, not just wt list

[worktrunk-bot]

wt config --help says "Invalid environment overrides are ignored with a warning; other valid overrides still apply." Only tolerant loads such as wt list behaved that way. wt switch, wt merge, wt remove, wt for-each, and the wt step commands reload config through UserConfig::load(), and load_with_cause treated a rejected override as fatal. These commands printed ▲ Ignoring env var overrides: … during the startup prewarm and then exited 1 with ✗ Failed to load config for the same variable.

load_with_cause now skips LoadError::Env. Every command falls back to the file layers for the rejected setting and keeps the other overrides, as the docs say. User-file parse errors, --config-set failures, and validation failures stay fatal for these commands.

With WORKTRUNK__LIST__BRANCHES=nope, wt step eval '{{ branch }}' now prints the one warning and outputs main (exit 0). test_eval_skips_invalid_env_override replaces the test that pinned the old exit 1.

A mistyped override such as WORKTRUNK__MERGE__REMOVE=flase or WORKTRUNK__REMOVE__DELETE_BRANCH=nope no longer stops wt merge or wt remove. The command warns and uses the file or default value instead.

The LoadError docstrings are updated too. Since #4348, LoadError::Env is emitted once per rejected setting, and strict loading no longer treats it as fatal.

[max-sixty]

why would we have different intended behavior?!

[worktrunk-bot]

@max-sixty, it shouldn't differ. The original sentence describes the intended design, and the strict commands contradict it. This PR's docs rewording documented a bug as behavior, so I'm replacing it with a loader fix.

Startup prewarm already loads the user config tolerantly and prints ▲ Ignoring env var overrides: …. The strict commands then reload through UserConfig::load(), and load_with_cause turns the same rejection into ✗ Failed to load config. So they say the override is ignored and then exit 1 because of it. The wt step eval test I cited as evidence of intent pins that contradictory output. It doesn't show a design choice.

The follow-up push makes load_with_cause skip LoadError::Env, keeps file, --config-set, and validation failures fatal, and restores the original doc sentence. The eval test now asserts that the command succeeds and prints the warning once.

One consequence needs your call before merge. A mistyped override such as WORKTRUNK__MERGE__REMOVE=flase or WORKTRUNK__REMOVE__DELETE_BRANCH=nope used to stop wt merge or wt remove. Now the command warns and falls back to the file or default value, which can mean removing the worktree or deleting an integrated branch. That matches the documented contract and wt list, but it loosens what gates a removal, so I'm leaving it to you.