Stop detaching usbip imports we cannot prove are ours

[potpiemuncher]

Fixes the follow-up filed at the end of #29, the same night, because it had already cost a real controller.

What happened

The UI verification in #29 launched a Thrum build on the dev PC while a native-mode DS4Windows build was serving a virtual DualSense over usbip during a game. Thrum's startup sweep detached it. The controller went dead mid-game, and VIIPER detached usbip port 1 (stale local VIIPER controller import) was the only trace.

Mechanism

DetachStaleLocalViiperPorts decided an import was our stale leftover if it:

1. came from a localhost usbip URL,
2. carried a VID/PID in KnownViiperDeviceIds, and
3. was not a port this process had registered.

Every one of those is equally true of a different application's live virtual pad.

The premise was the defect, not the heuristic's precision: a local import cannot be attributed from the port table at all. The usbip link records the serving side and never the consumer, so a dead session's leftover and a live consumer's device are literally the same row. No refinement of the VID/PID list fixes that.

Arriving with #28, not #29 — but #29 is where the irony lives, since its whole (d) story is "a backend we did not start is not ours to stop" while this sweep had no ownership test at all.

The fix

ObserveLocalImports replaces the sweep and detaches nothing. It reads the port table, names any local import this session does not manage in one log line pointing at the (d) backend-process card — which can attribute leftovers through the backend census and clear them with consent — and leaves them alone.

3.3's rule is kept exactly: an unreadable port list is not an empty one, and still refuses creation (ViiperImportObservation carries that verdict).

Two narrower attribution bugs surfaced while proving the above, each able to detach somebody else's device on its own:

• FindLocalViiperPort matched by bus id alone. usbip bus ids are small integers every server counts from the bottom, so two local servers can both serve a 1-7 — the first hit won, and teardown then detached it. It now refuses on ambiguity (-1, rolling the creation back) rather than guessing, and prefers the usbipPort the backend reports in the create response (upstream viipertypes.Device, added 2026-07-30) over scanning at all. Older backends fall back to the scan.
• DetachDuplicateLocalViiperPorts is now scoped to the usbip://host:port/ prefix of the import we confirmed as ours, so a same-bus-id device on a different local server is out of reach. No confirmed import, no prefix, no detaching.

KnownViiperDeviceIds is deleted. Nothing in this class decides what an import is from its controller identity any more; the only identity test left is whether the server is loopback.

What this gives up, deliberately

Automatic cleanup of a genuine leftover from a hard-killed session. That becomes a consented user action via the (d) card — the same trade (d) already makes, for the same reason: the application cannot prove the thing is abandoned. The startup self-ingestion risk the sweep originally guarded is accepted as residual and called out at its ControlService call site; the (d) startup warning fires on exactly that state.

Verification

Suite: 862 passed / 0 failed (CI filter), from 853.

Sixteen tests in ViiperImportObservationTests (replacing ViiperStalePortSweepTests, whose verdict cases carry over): the observation verdict, the report line's required content, and the attribution rules — bus-id matching that rejects /1-7 against /1-71, ambiguity refusing to guess, remote imports never attributed locally, duplicate detach scoped to one server, and no-confirmed-import meaning no detaching.

Reproduced against the original failure, live. With the native-mode DS4Windows still serving its DualSense on port 1, the fixed build was launched isolated: usbip port showed the import unchanged before and after, four Sony devnodes stayed present, and the controller survived both Thrum start and shutdown. The log carried the report the detach became:

1 local usbip import(s) present that Thrum does not manage (port 1): left untouched -
they may belong to another application or to a backend from a previous session. If one
is a leftover virtual pad, Settings > VIIPER Virtual Controller Support > Backend
process can clear it.

🤖 Generated with Claude Code