feat: Tailcat dial-direction / serve option for federated peers (no cloud Tailscale)

[atomanticagent]

Motivation

Home PortOS can start a local tailcat forward to a sandbox's serve, but dials time out (context deadline exceeded / tunnel_dial). Sandbox self-dials fine via DERP. Likely client firewall or path asymmetry: the sandbox is a good initiator.

Operators want a PortOS UI option for reverse polarity (this node serves / or dials outbound) and longer-term: wire federated nodes with per-node tailcat serve+forward instead of cloud-run Tailscale.

Desired outcome

1. Serve mode managed by PortOS (machine-local): start/stop tailcat serve for PortOS API port 5555, persist config, API + Instances UI with copyable tc… address, restore on boot.
2. Dial-direction when adding peers: Dial them (existing forward) vs They dial us (we serve, share our address).
3. Docs update for when to use each polarity + fleet sketch; firewall/Little Snitch note.
4. Tests for serve lifecycle (mocked spawn), API shapes, UI mode switching.

Constraints

• No Tailscale account/daemon, no serve all, no exit-node.
• Reuse ensureTailcatInstalled; placeholders only for tc… in commits/docs/tests.
• Verbose forward diagnostics / tunnelError patterns stay.

Related

• Existing forward peer add (feat: federated peers via tailcat (no Tailscale account) #6401+)
• Peer card forward status + probe diagnostics (feat: Tailcat peer card forward status + probe diagnostics #6478)