FP-7: Studio physical-device docs were stale — code has supported them since v0.7.0

[pbertsch]

Summary

FP-7 asked me to wire the CLI's existing internal/device physical-device management (iproxy for iOS, adb for Android, WiFi mode) into FlutterProbe Studio's Go backend and device picker, since Studio's own docs claimed physical iOS/Android weren't supported.

Investigation finding: the wiring already exists. studio/app.go's Connect()/ConnectWiFi() already call internal/device's EnsureIProxy, EnsureADB/ForwardPort, IsPhysicalIOS/IsPhysicalAndroid — the exact same code the CLI uses — and the frontend (studio/frontend/src/main.ts + index.html) already has a device picker with a physical tag, a WiFi discovery overlay (mDNS _flutterprobe._tcp), and token-memory UX. This shipped in #85 (feat(studio): physical-device support over USB) and #86 (feat(studio,agent): mDNS auto-discovery for WiFi physical devices), both already on main as of v0.7.0 — well before this ticket. git merge-base --is-ancestor confirms both are ancestors of the current main HEAD.

What was actually stale and inconsistent: website/src/content/docs/tools/studio.md — the Beta Preview banner, feature list, System Requirements, Frame Rate table, and Known Limitations section all still said "Physical devices are not supported (no iproxy management in Studio yet)." That's the real inconsistency the ticket description was pointing at, just one layer removed from where I expected it.

What changed

• website/src/content/docs/tools/studio.md — rewrote every stale claim to match actual behavior:
  • Beta Preview banner and feature list now mention physical device support
  • New "Physical devices" section: USB flow (iproxy for iOS / adb forward for Android) and WiFi flow (mDNS discovery, preferred for iOS per this project's own USB-C-instability findings from AGENTS.md)
  • System Requirements lists libimobiledevice/adb prerequisites
  • Frame Rate table corrected (no longer says "n/a — not supported")
  • Known Limitations corrected to the one real gap: the WiFi overlay only connects to mDNS-discovered devices — no manual host/port entry field, so devices that don't advertise (older agent builds, mDNS-blocking networks) still need the CLI's --host/--token flow. I deliberately did not build that manual-entry UI in this PR — flagging it honestly rather than scope-creeping a UI feature into a docs-fix PR.
• studio/app_test.go (new) — the studio module had zero test coverage before this. Added tests for the pure/testable surface: isDeviceReady, extractLineCol, ReadFile/WriteFile path guards (extension + traversal), Lint (parse errors, empty-test warnings, valid scripts), ListDir, Status/activeClient/Disconnect when unconnected, and Connect/ConnectWiFi input validation (unknown device ID, empty ID, missing WiFi params).
• CHANGELOG.md — [Unreleased] entry documenting the fix.

What I found and corrected mid-investigation

While drafting the docs I initially wrote that physical-device connections in Studio use HTTP transport (mirroring the CLI's behavior per AGENTS.md's Transport Modes table). Checking app.go more carefully: Studio's Connect()/ConnectWiFi() both always call probelink.DialWithOptions, which is WebSocket-only (ws://) — there's no HTTP client path in Studio at all, unlike the CLI which auto-selects HTTP for physical devices. I corrected the docs to say WebSocket, not HTTP. This is a genuine (undocumented, but shipped and apparently intentional) difference in transport choice between the CLI and Studio; I did not change the code, only made sure the docs I wrote were accurate to what the code does.

Test plan

• go build ./... (root) — clean
• go test ./... (root) — all packages pass
• cd studio && go build ./... — clean
• cd studio && go vet ./... — clean (staticcheck flags two pre-existing, unrelated issues in ai_chat.go/wifi_discovery.go — not touched by this PR)
• cd studio && go test ./... -v — all 20 new tests in app_test.go pass
• cd studio/frontend && npm install && npm run build — clean
• cd studio && wails build — full desktop build succeeds end-to-end (macOS arm64, self-signed .app produced)
• cd website && npm ci && npm run build — clean; confirmed the new #physical-devices anchor renders in the built HTML for the in-page link from Quick Start

What still needs manual/hardware verification before merge

This PR is documentation + tests only — no application code changed, so the physical-device feature itself was not re-verified against real hardware by me:

• A physical iOS device over USB (iproxy tunnel path) — I don't have one attached in this sandboxed environment
• A physical Android device over USB (adb forward path) — same
• The WiFi mDNS discovery + connect flow against a real device advertising _flutterprobe._tcp
• The actual frame rate on a physical device (I wrote "not separately benchmarked yet" rather than inventing FPS numbers — if you have real numbers from prior testing, the Frame Rate table row should get pinned to a real figure instead of the current qualitative description)

Since the underlying Connect/ConnectWiFi/EnsureIProxy/EnsureADB code is unchanged (already shipped and already used by the CLI's own physical-device flow, which — per project memory — has been live-verified with zero connection drops over WiFi), I'd expect this to work, but I have not personally confirmed it end-to-end against hardware in this session.