bug(rp2040): reject unrelated pre-existing CDC port after stock-ROM deploy

[zackees]

Parent: #1040 and #1049. FastLED/FastLED#3627 and #3648 depend on this safety condition.

Reproduction (2026-07-15, fbuild-only)

Precondition from fbuild port scan:

COM12  2E8A:000A  Raspberry Pi Pico SDK CDC UART  ser=5303284720C4641C

A separate Pico was already in stock ROM USB / RPI-RP2 mass-storage mode at G:. It has no CDC port by design. Run from FastLED with the editable fbuild development install:

FBUILD_DEV_MODE=1 UV_NO_SYNC=1 bash autoresearch rp2040 --rpc-smoke --timeout 120s --skip-lint --clean

Observed decisive lines:

Target rp2040 @ None
wrote G:\NEW.UF2
Deploy succeeded (full flash); FBUILD_DEPLOY_PORT=COM12
RESULT: RPC smoke PASS

Immediately after the command, both fbuild port scan and fbuild serial probe list still showed only the exact pre-existing COM12 / serial 5303284720C4641C; no new post-deploy CDC endpoint appeared. The RPC command therefore talked to the unrelated pre-existing replacement board and produced a false green result.

Expected

For an already-mounted stock ROM target with no selected runtime identity, deployment must fail closed unless the post-deploy CDC endpoint is demonstrably associated with the selected BOOTSEL volume. It must never return an unrelated pre-existing CDC port or let AutoResearch run RPC against it.

A correct solution may accept a re-enumerated same-name port only when board serial/topology/other stable identity correlates it to the selected target. If correlation is unavailable, require a new/associated endpoint or return the existing typed CDC-handoff/recovery failure.

Acceptance

• Add a focused regression test with a pre-existing unrelated CDC candidate and a selected BOOTSEL volume; no correlated/new runtime endpoint must be an error, never success with that port.
• Preserve valid subsequent deployment where a selected runtime can be correlated across reset, including COM-name reuse.
• Do not hard-code production RP2040 VID/PIDs; use the generated FastLED/boards catalogue and synthetic IDs only in fixtures.
• Validate with fbuild tests, then repeat the canonical fbuild-only stock-ROM AutoResearch command. The returned port must be newly observed or identity-correlated to the selected board.

This is a deploy-result correctness defect, not evidence of QSPI failure. No PlatformIO or direct-flash workaround is in scope.

[zackees]

Investigation correction (2026-07-15)

The initial report inferred a stale-port handoff from wrote G:\NEW.UF2 followed by FBUILD_DEPLOY_PORT=COM12. The fbuild daemon log resolves that ambiguity:

deploy: selected COM12 — Raspberry Pi Pico SDK CDC UART (2E8A:000A)
RP2040 1200-bps reset reported an error, but BOOTSEL appeared; continuing
volume=G:\

Therefore this run had selected COM12 before the RP2040 deployer observed G:. The BOOTSEL transition can be COM12 itself resetting and returning on the same port name; it is not evidence that an unrelated pre-existing CDC port was returned. The physical run is a subsequent-deployment attempt on serial 5303284720C4641C, not stock first-deployment proof for a second board.

Current main (and the editable source commit used) already snapshots pre-deploy CDC ports and fails with the typed CDC-handoff failure when only pre-existing ports remain. Focused confirmation:

bash test -p fbuild-deploy -- cdc_timeout_after_transfer_is_an_actionable_failure
1 passed; 0 failed

No code change is justified by this reproduction. Closing as invalid after preserving the evidence; #1040/#1049 remain open for a genuine stock-ROM first-deploy acceptance run with the board identity recorded.

[zackees]

Closed after investigation: the reported stale-port condition was not reproduced; see the evidence comment.