Support explicit remote HTTP daemon endpoint for agent-device client

[thymikee]

Problem

agent-device supports HTTP daemon mode, but the client still assumes the daemon is local:

• daemon metadata is read from the local state dir
• HTTP and socket transport connect to 127.0.0.1
• when metadata is missing, the client auto-starts a local daemon

That prevents a clean remote-host setup where:

• an AI agent runs inside a Linux sandbox
• the sandboxed agent uses plain agent-device ...
• the actual daemon runs on a remote macOS host
• the remoting is opaque to the sandboxed agent

Today this requires an additional proxy/shim layer that impersonates agent-device transport.

Requested capability

Add explicit remote daemon endpoint support to the agent-device client.

Suggested shape:

• env: AGENT_DEVICE_DAEMON_BASE_URL=http://<host>:<port>
• optional flag: --daemon-base-url <url>
• optional auth support:
  • AGENT_DEVICE_DAEMON_AUTH_TOKEN
  • or a generic auth-header/token option

Expected behavior

When daemon base url is set, the client should:

• skip local daemon startup
• skip local daemon.json endpoint discovery for transport resolution
• send JSON-RPC requests directly to the configured remote HTTP daemon
• preserve normal agent-device CLI UX for commands like:
  • agent-device open App
  • agent-device snapshot -i
  • agent-device click @e3

Why this matters

This enables a cleaner architecture for remote macOS execution:

• sandbox agent uses real agent-device
• macOS host runs real agent-device daemon in HTTP mode
• auxiliary sidecars only handle concerns agent-device does not cover, such as artifact upload or Metro bridging

instead of requiring a separate command-proxy shim for all agent-device calls.

Notes

The current HTTP daemon mode from PR #136 is useful, but it is still loopback-oriented:

• local state dir metadata
• 127.0.0.1 connection assumptions
• local daemon auto-start

This issue is specifically about making the client support an explicitly configured remote daemon endpoint.