Windows: Backspace in $EDITOR=vim.exe launched via Ctrl+G inserts ⌂ (0x7F) instead of deleting

### Repro
- Windows 11, PowerShell (conhost or Windows Terminal)
- Copilot CLI v1.0.49-1
- Vim 9.2 (console build) at `C:\Program Files\Vim\vim92\vim.exe`

```powershell
$Env:EDITOR = "$Env:ProgramFiles\Vim\vim92\vim.exe"
copilot
# Press Ctrl+G (or Ctrl+X then e) to edit the prompt in $EDITOR
# In Vim, press `i` for insert mode, type some text, press Backspace
```

### Expected
Backspace deletes the previous character.

### Actual
Backspace inserts the `⌂` glyph (CP437 rendering of byte `0x7F` / DEL).

### Notes
- Vim launched directly from the same PowerShell session (`& $Env:EDITOR`) works correctly — Backspace deletes as expected. The bug only reproduces when Vim is spawned by Copilot CLI's external-editor feature.
- Apparent root cause: Copilot CLI puts the Windows console into VT input mode (ConPTY) for its own TUI. With `ENABLE_VIRTUAL_TERMINAL_INPUT` set, Backspace is delivered as `0x7F` (`^?`, xterm style). Vim's Windows console build defaults to `t_kb=^H` (`0x08`), so it does not recognize `0x7F` as Backspace and inserts it as a literal character (displayed as `⌂`).
- The editor is spawned via plain stdio inheritance (no PTY bridge), so the parent's VT input mode leaks into the child.

### Possible fixes? (Unverified)
- Allocate a PTY for the editor subprocess, or
- Temporarily clear `ENABLE_VIRTUAL_TERMINAL_INPUT` on the console before spawn and restore after, or
- Set `TERM=win32` in the spawned editor's environment so Vim picks compatible termcap defaults.

### Environment
- OS: Windows 11
- Shell: PowerShell
- Copilot CLI: 1.0.49-1
- Vim: 9.2 (console build, `vim.exe`)