Fix for ESP-32 Boards Being Flashed with a Programming Board (e.g. ESP-PROG)

[JandCandO]

Bug:

When micropico.autoConnect is false and micropico.manualComDevice is set to a valid COM port running MicroPython, the extension silently fails to connect if the USB-to-serial adapter's VID/PID is not in the hardcoded whitelist.

Steps to reproduce

1. Connect an ESP32 running MicroPython via an ESP-PROG (FTDI FT2232, VID 0x0403, PID 0x6010)
2. Confirm MicroPython is reachable: mpremote connect COM5 eval "print('hello')" works
3. Set micropico.autoConnect: false
4. Set micropico.manualComDevice: "COM5"
5. Reload VS Code
6. Run MicroPico: Connect — nothing happens, no error shown
7. If manualComDevice is cleared, you get "No board running MicroPython has been found"

Root cause

PicoMpyCom.getSerialPorts() filters ports by VID/PID before returning them. The setupAutoConnect() method in activator.mts, which fails because the FTDI port was already filtered out. The connect command (L450) has the same issue.

The manualComDevice setting exists specifically for cases where auto-detection doesn't work, yet it's still subject to the same VID/PID filtering it's meant to bypass.

Expected behavior

When manualComDevice is explicitly set, the extension should attempt to open that port directly without requiring it to pass VID/PID filtering. The user has explicitly told the extension which port to use.

Suggested fix

In setupAutoConnect() and the connect command handler, when manualComDevice is set, open the port directly via PicoMpyCom.getInstance().openSerialPort(manualComDevice) instead of requiring ports.includes(manualComDevice).

Environment

MicroPico v4.3.4
VS Code (Windows)
ESP32 connected via ESP-PROG (FTDI FT2232H, VID 0x0403, PID 0x6010)
MicroPython v1.x on ESP32
Workaround
Manually patch dist/extension.js to add 1027 (0x0403) to the VID array ht and 24592 (0x6010) to the PID array gt. This survives until the next extension update.