acq exec/run on msb don't forward the host terminal identity (TERM/COLORTERM), so TUI agents fall back to a 16-color palette #425

Summary

On the msb backend, interactive sessions started through acq run (attach) or acq exec see TERM=linux and no COLORTERM, regardless of the host terminal. TUI agents that render on the terminal's reported capabilities — OpenCode with "theme": "system", for example — conclude they're on a 16-color console and fall back to their built-in palette. The same sandbox contents attached through the sbx backend render correctly, because sbx forwards TERM and COLORTERM from the host.

Repro

1. Create an msb sandbox and attach from a truecolor terminal (TERM=xterm-256color, COLORTERM=truecolor on the host).
2. acq --backend msb exec <name> -- sh -c 'echo TERM=$TERM COLORTERM=$COLORTERM' → prints TERM=linux COLORTERM=.
3. Launch a TUI agent via acq --backend msb run <name>: colors are wrong (fallback gray palette). The identical setup on sbx renders the host palette.

Root cause

msb exec does not propagate the caller's terminal environment into the guest PTY, and acq's msb exec/attach paths don't compensate: _acq_msb_exec_flags_into threads kit environment: entries and the non-interactive git guards as -e flags, but never the host's TERM/COLORTERM. The sbx backend needs no equivalent because the sbx CLI forwards both itself.

Proposed fix

On the interactive exec/attach paths, forward the host values when set: -e TERM=$TERM -e COLORTERM=$COLORTERM (same -e treatment the git guards already get; skip when unset rather than inventing values). Guests that lack the matching terminfo entry degrade no worse than today, and kits can supply the full DB (the team-data kit already installs ncurses and sets TERMINFO_DIRS).

Related

Sibling of #421: same defect class — the msb exec/attach path missing session context that sbx provides (working directory there, terminal identity here) — and the fix lands in the same functions, so one small "msb exec/attach parity" PR could close both.