[Bug] Resumed session injects COLORTERM=truecolor and changes prompt highlight color

### Describe the bug

Resuming a Copilot CLI session can inject `COLORTERM=truecolor` into the spawned session process even though the launching shell and parent Copilot process have `COLORTERM` unset. This changes the submitted-user-prompt highlight from the terminal-palette green rendering to a gray truecolor background.

The result is inconsistent UI rendering between two Copilot sessions launched by the same WSL user, with the same global `theme: "github"` setting, the same Windows Terminal profile, and `TERM=xterm-256color`.

Process inspection showed:

- Direct launch from Bash:
- process is a direct child of the login shell;
- `COLORTERM` is unset;
- submitted user prompts have a green highlight.
- Resumed session:
- `copilot --allow-all --remote --resume` spawns a child Copilot process with `--session-id`;
- the shell and parent Copilot process have `COLORTERM` unset;
- the spawned child has `COLORTERM=truecolor`;
- submitted user prompts have a gray highlight.

There is no repository-local Copilot setting or Git color configuration explaining the difference. `copilot help config` exposes only whole-theme presets and no prompt-background setting.

### Affected version

GitHub Copilot CLI 1.0.76-3

The long-running resumed session was originally started on an earlier 1.0.76 build and survived CLI updates, but the current process/executable reports 1.0.76-3.

### Steps to reproduce the behavior

1. Open a fresh WSL2 Bash shell in Windows Terminal.
2. Confirm the variable is absent:

```bash
printenv COLORTERM
```

3. Launch Copilot directly:

```bash
copilot --allow-all --remote
```

4. Submit a prompt and observe the user-message highlight.
5. In another fresh shell with `COLORTERM` still unset, resume a saved session:

```bash
copilot --allow-all --remote --resume
```

6. Select a session, submit a prompt, and observe that the highlight color differs.
7. Inspect the processes:

```bash
ps -eo pid,ppid,args | grep '[c]opilot'
tr '\0' '\n' /environ | grep -E '^(TERM|COLORTERM|WT_SESSION)='
```

8. Observe that the resumed child has `COLORTERM=truecolor`, while its parent Copilot process and launching Bash shell do not.

### Expected behavior

Copilot CLI should preserve the launching terminal's color-capability environment consistently across direct, resumed, and restarted sessions.

A resumed child process should not inject or change `COLORTERM` relative to its launching shell/parent. With the same terminal and `theme` setting, submitted user prompts should render with the same highlight colors.

### Additional context

- OS: WSL2 Linux, x86_64
- Terminal: Windows Terminal
- Shell: Bash login shell
- `TERM=xterm-256color` in both sessions
- Same Windows Terminal profile ID in both sessions
- User setting: `"theme": "github"`
- No repository-local theme/config override found
- The only observed discriminator was `COLORTERM=truecolor` on the resumed child

Related open issues:

- #3591 — user prompt visual distinction/configuration
- #4292 — truecolor-related rendering differences
- #4212 — prompt/highlight rendering differs by terminal context

This report is narrower: it concerns Copilot CLI's resumed-session process launch changing `COLORTERM`, producing different rendering without any terminal, user, repository, or theme-setting change.

Reproduce direct and resumed launches in WSL2 Bash, then inspect the resumed child with ps and /proc//environ as described. Trace how the --session-id child is spawned and ensure it preserves the launching shell's COLORTERM state; done means direct, resumed, and restarted sessions render the same prompt highlight under the same terminal settings.

Written by the indexing model from the issue text.