feat(roku): add Roku platform support

[namidan]

Proposed changes

copilot:summary

Adds Roku as a supported platform (--platform roku), following the integration patterns established by the tvOS and Vega ports. Contributed by teams Nami and rku.dev.

• Driver (drivers/RokuDriver.kt + maestro/roku/): Roku devices are driven over the External Control Protocol (an HTTP API on device port 8060) — no on-device agent. View hierarchy comes from /query/app-ui (SceneGraph XML parsed into scene-absolute bounds), input is D-pad keypresses (tapOn sends Select; swipes/scrolls become directional presses), text is typed via character-by-character LIT_ keypresses, and screenshots go through the dev web server (digest auth). launchApp is a cold launch: an already-running channel is exited to the home screen first.
• Device discovery: DeviceService.listRokuDevices() surfaces devices through the normal listing/selection path — a MAESTRO_ROKU_HOST pin (fast reachability probe) plus an opt-in SSDP LAN scan (MAESTRO_ROKU_DISCOVERY=true). No new global CLI flags and no TestCommand special-casing.
• Platform wiring: Platform.ROKU, DeviceSpec.Roku, RokuLocale, session managers (CLI + MCP), pickers, start-device, AppValidator.
• New KeyCodes Remote Info (the * options button), Remote Instant Replay, Remote Search — mapped on Roku and Android; Remote Menu maps to Roku's options button.
• Studio TV mode auto-enables for Roku, like tvOS.
• e2e fixture: a BrightScript demo channel (e2e/roku_demo_app/) mirroring the tvOS/Vega demo apps — same screens, labels, and testIDs (Home menu, 2×2 navigation grid, native-Keyboard text input, programmatic-focus test) — with three mirrored flows under e2e/workspaces/roku_demo_app/.
• Docs: FORK.md platform entry (device setup, env vars, key names) and README feature bullet.

Notable device-behavior quirks handled (all reproduced on hardware): the dev server's multipart parser ignores form parts carrying a per-part Content-Length header (so the screenshot form is assembled by hand with an explicit digest handshake), the screenshot file is written asynchronously (the download polls its ETag against the pre-generation value), and ECP keypress path segments must be percent-encoded (a form-encoded space would type a literal +).

Testing

• Unit tests (14, in maestro-client/src/test/java/maestro/roku/): app-ui parser (bounds math, translation offsets, RowListItem duplicate-drop, focus state), key mapping, SSDP response parsing, ECP path-segment encoding, and the dev server's digest challenge. ./gradlew :maestro-client:test --tests "maestro.roku.*"
• On-device validation against a physical Roku Streaming Stick 4K (Roku OS 14) in developer mode: all three demo-channel flows pass end-to-end (maestro test --platform roku e2e/workspaces/roku_demo_app/), covering launch, all four D-pad directions, focus asserts (focused: true/false by id), programmatic focus, inputText with spaces/capitals, eraseText, Back-driven screen returns, and takeScreenshot (captures visually verified against the asserted screen state).
• CLI smoke tests: list-devices shows a pinned Roku (and degrades gracefully in ~5s when the host is unreachable); start-device --platform roku without MAESTRO_ROKU_HOST produces an actionable error.
• Full-project compile and the maestro-client/orchestra/cli/maestro-test suites pass (one pre-existing FlutterWebSemanticsIdentifierTest failure exists on main independently of this change).

Does this need e2e tests? Covered, but not in e2e/demo_app/ — the Flutter demo app can't run on Roku, so this PR follows the tvOS/Vega precedent instead: a dedicated fixture app (e2e/roku_demo_app/, BrightScript) plus flows in e2e/workspaces/roku_demo_app/, mirroring those apps' screens, labels, and testIDs. Flows require physical Roku hardware (there is no emulator), so they are not wired into CI — same as the Vega suite.

Issues fixed

None — new platform capability.