feat: Cloudflare Tunnel remote access — secure HTTPS without port exposure

[rexlunae]

Inspiration: Unsloth

Unsloth provides --cloudflare / --secure flags that create a Cloudflare Tunnel for HTTPS access. Critically, it fails closed — the raw port is never exposed to the internet. If the tunnel can't start, the service stays localhost-only.

From Unsloth docs:

Unsloth stays bound to localhost and is reached only through a free Cloudflare tunnel, which publishes it at a public https://*.trycloudflare.com URL (it fails closed if the tunnel can't start, so the raw port is never exposed).

What RustyClaw could do

Add a secure remote access mode for the RustyClaw gateway:

1. rustyclaw gateway start --tunnel — starts gateway bound to localhost, creates a Cloudflare tunnel for external access
2. Fail closed: If tunnel setup fails, gateway stays localhost-only (never falls back to binding 0.0.0.0)
3. Authentication: Tunnel requires the gateway's API key, never exposes unauthenticated access
4. Optional custom domain: For users with their own Cloudflare domains, support --tunnel-domain myagent.example.com

Why this matters

RustyClaw users want to access their agents remotely (phone, different machine). Port forwarding is insecure, VPN setup is complex. Cloudflare Tunnel is free, secure, and requires no router configuration.

Scope

• rustyclaw-core: Cloudflare tunnel integration (via cloudflared binary or Rust tunnel crate)
• rustyclaw-cli: --tunnel flag on gateway start
• Security review: ensure tunnel auth + gateway auth are both enforced
• Feature flag: cloudflare-tunnel (adds cloudflared dependency requirement)

Prior art

• Unsloth: https://unsloth.ai/docs/basics/cloudflare (referenced in docs)
• cloudflared: https://github.com/cloudflare/cloudflared
• cloudflare-tunnel Rust crate concept (or exec cloudflared as subprocess)
• Many self-hosted tools use this pattern (Home Assistant, code-server, etc.)