feat(macos): wire remote-control status + machine registry management

[andrei-hasna]

Summary

The macOS Machines screen was list/pairing-only and never surfaced remote-control availability/status, machine trust management, or the remoteDispatch actions the app-server already exposes. This wires the missing client surface end-to-end.

App-server API (Backend/AppServerAPI.swift)

• remoteControl/status/read, remoteControl/enable, remoteControl/disable
• machineRegistry/read, machineRegistry/updateTrust, machineRegistry/disable, machineRegistry/forget
• remoteDispatch/negotiate, remoteDispatch/submit
• Static camelCase param builders matching the Rust serde defs in app-server-protocol/src/protocol/v2/{remote_control,machine_registry,remote_dispatch}.rs and the method-name registrations in common.rs.

Models (Backend/BackendModels.swift)

• RemoteControlStatusInfo, RemoteDispatchNegotiationInfo, RemoteDispatchSubmitInfo, MachineTrustState
• MachineInfo.trustState
• Submit status is kept verbatim so the camelCase dryRun value survives (not lowercased).

App model (App/AppModel.swift)

• remoteControlStatus state + loadRemoteControlStatus() (run from refreshAll and the Machines settings tab)
• setRemoteControlEnabled, updateMachineTrust, disableMachine, forgetMachine
• remoteControl/status/changed notification handler that applies the new status and refreshes the fleet
• All new paths degrade gracefully on older servers via the existing isUnsupportedMethodError handling.

UI (Screens/MachinesView.swift)

• Remote-control availability/status banner with an enable/disable toggle
• Per-machine context menu for trust / disable / forget (omitted for the local machine)
• Existing list/pairing flows untouched.

Design note: no spawn-time --remote-control flag

Remote control is enabled at runtime via remoteControl/enable rather than the hidden --remote-control spawn flag. The app-server always stands up its remote-control handle for the stdio transport (and the websocket task lazily derives its target from the URL when enabled flips true), so the flag is unnecessary. Passing it would (1) hard-crash older bundled/installed builds — clap rejects unknown args at launch, killing the whole JSON-RPC connection, not just remote control — and (2) force remote control on at every launch with no user opt-in (server-side enable/disable is in-memory only).

Testing

• Added BackendTests coverage for the new param builders and decoders (exact camelCase keys, trust-state raw values, dryRun status preservation).
• No Swift toolchain / macOS CI on the build host (Rust/Python only), so swift build/swift test could not be run here; validation was static cross-checking of every method string and field name against the Rust protocol source, plus the added XCTest coverage for macOS CI/reviewers.

🤖 Generated with Claude Code