fix(settings): stop the command-color toggle from wiping the default shell

Review fixes on top of the opt-in command-color change.

Both terminal settings share one stored row and the save replaces it whole,
so the color switch has to send `default_shell` back verbatim. It did — but
only when the row had actually been read. After a failed load (a network
blip on a remote workspace is enough) the switch was still live with
`storedDefaultShell` at its `null` initial value, and one click persisted
"use the system shell" over whatever the user had configured. The shell
picker was already inert in that state; the switch now is too, via a
tri-state where `undefined` means "not loaded" and `null` keeps meaning
"system".

The two Rust tests that exercise the save both write `FORCE_COMMAND_COLOR`,
a process global, and ran concurrently — `set_system_terminal_settings_core`
awaits between storing the flag and returning, which is exactly where the
other test's store lands. They now serialize on a mutex and restore the flag
through a drop guard, so a failed assertion can't strand it for the next run.

`colorize_command_output_persists_and_reaches_the_launch_env` also now
asserts on a real launch env rather than only on the global, closing the one
step its name promises and the pure-function tests can't reach: whether
`merge_agent_env` reads the flag at all.

Also: the description now says the setting takes effect on new sessions
(it is read while building a launch's env), matching the existing wording on
the Kimi reasoning setting; the startup-failure log names both values it
failed to apply; and the two startup-ordering comments say why the ordering
is now load-bearing for the color flag, not just the shell.