Reverse 8081 only when the debug_http_host write fails

[janicduplessis]

Closes #142

Description

launchAndroidApp registered two adb reverse pairs before writing debug_http_host:

tcp:8081        -> tcp:<metroPort>
tcp:<metroPort> -> tcp:<metroPort>

Once the prefs write lands the app asks for <host>:<metroPort>, which the second pair serves. The first is unused. I checked rather than assumed: deleting tcp:8081 from under a running app on a physical device and triggering a full reload, the app re-bundled and came back with only tcp:8082 -> tcp:8082 present.

That matters because tcp:8081 is the one device port every workspace competes for, and re-registering a device port silently replaces the previous entry -- no error, no warning. A run that does not need the mapping should not be entering that contention, and an unused cross-port entry in adb reverse --list is a misleading thing to find when debugging.

Solution

Register tcp:8081 -> tcp:<port> only when the debug_http_host write fails, which is exactly when the app is left asking for its compiled-in default.

Removing it outright would have been wrong. The write goes through run-as, which fails on a non-debuggable app and under a secondary Android user. Today that is a warning and the app still loads; with no fallback at all it would become "the app loads no JS", and the existing relying on adb reverse note would be false. Ordering the fallback behind the failure keeps that degraded path working while taking it off the healthy one.

reverseMetroPorts now takes the device ports to map rather than deriving them from metroPort, so the fallback is one explicit call instead of a flag that re-registers the same-port pair.

The wired line printed a fixed tcp:8081 -> tcp:<port> string regardless of what was registered, so it would have started lying after this change. It now reports what launchAndroidApp actually returned.

Risk

The behavior change is that a healthy run no longer registers tcp:8081. Anything outside Stim that assumed the app is reachable on device port 8081 -- a hand-run curl, another tool's expectation -- loses that on a healthy run. Nothing in Stim depends on it: the app follows debug_http_host, and the collector and launch verification go through the serial, not the port.

Reverting is a one-file change.

Test plan

Verified on a physical Samsung SM-G996W with stim android --device --variant previewDebug, after clearing every mapping with adb reverse --remove-all:

wired       debug_http_host localhost:8082 + adb reverse tcp:8082->tcp:8082
verify      ready: bundle loaded, stable for 3s, process alive (4.5s total)

$ adb -s RFCR7081Q9L reverse --list
UsbFfs tcp:8082 tcp:8082

One mapping, same port both sides, and the app still bundles. The failed-write path is covered by a unit test that makes run-as throw and asserts the 8081 fallback is then registered and the existing note is emitted.