feat: Multi-target LAN routing (Cloudflare Tunnel-style)

[osa911]

Summary

• One CLI instance now serves ALL user tunnels — no more running separate CLI per service
• Each tunnel maps a domain to a target_host:target_port in the local network (e.g., app.example.com → 192.168.1.5:8080)
• Dashboard changes push to connected CLI in real-time via gRPC ConfigUpdate messages
• giraffecloud connect — no --domain flag needed, serves everything

Changes

Database & API

• Added target_host field to Tunnel schema (default: localhost) with composite unique index on (user_id, target_host, target_port)
• Removed per-tunnel token field (auth uses API tokens only now)
• Updated repository, DTOs, mapper, service validation, and handler

Protocol & gRPC Server

• New proto messages: TunnelRouteConfig, ConfigUpdate, ConfigUpdateReason
• EstablishTunnel registers one gRPC stream for ALL user domains
• ControlChannel uses token-based lookup via userStreams map
• PushConfigUpdate pushes live config changes when tunnels are created/updated/deleted

CLI

• New RouteTable maps domains to LAN targets
• gRPC client populates route table from handshake and handles live ConfigUpdate
• Connect() simplified — just token, no domain/port
• --domain flag removed

Frontend

• "Target Host" input in tunnel create/edit dialog (default: localhost)
• Tunnel list shows full host:port target
• Getting Started page updated for new flow

Docs

• README, installation, architecture docs, llms.txt updated

Test plan

• Create tunnel with default target (localhost:port) — verify backward compat
• Create tunnel with custom target_host (LAN IP:port) — verify routing
• Connect CLI with giraffecloud connect — verify all tunnels served
• Add/edit/delete tunnel in dashboard while CLI connected — verify live ConfigUpdate
• Disconnect CLI — verify all Caddy routes cleaned up
• Verify uniqueness constraint: same host+port per user rejected

🤖 Generated with Claude Code