fix(acp): make the command-color toggle reach the commands agents run

Turning "Colorize command output" on injected `CLICOLOR_FORCE=1` and nothing
else, which left it inert for most of what an agent actually runs.
`CLICOLOR_FORCE` is only half of the BSD contract: in `ls` the enable decision
(`CLICOLOR`) and the isatty waiver (`CLICOLOR_FORCE`) are separate conditions,
so forcing without enabling still came back monochrome. The npm toolchain
behind `pnpm build` reads `FORCE_COLOR` and ignores both. And `TERM` gates the
rest — `ls` resolves its palette through `tgetent(getenv("TERM"))`, while a
codeg started from Finder passes no TERM at all, so the packaged app could
never colour what the dev build did.

An opted-in launch now carries all four: `CLICOLOR=1`, `CLICOLOR_FORCE=1`,
`FORCE_COLOR=1` and `TERM=xterm-256color`. TERM is the one entry that
overrides an inherited value rather than filling in a missing one, on purpose:
the agent's stdout is a pipe and never a terminal, so an inherited TERM
describes the shell that happened to start codeg, not anything the agent is
attached to, and pinning one known-good entry is what makes a packaged app
behave like `pnpm tauri dev`.

Precedence is unchanged — a per-agent env row still outranks every one of
them — but exempting an agent takes empty values rather than `0`: the BSD pair
is presence-checked, so `CLICOLOR_FORCE=0` still reads as forced, while an
empty value is what the spawn layer turns into `env_remove`. The default is
still off, and both the merge tests and the persistence test now assert the
whole set in both directions instead of one representative variable.