Modernize Tailscale Funnel setup and migration guidance

[qayshp]

Summary

• replace the redundant Tailscale Serve-plus-Funnel flow with one background Funnel command
• add migration guidance for older persisted Serve routes without resetting unrelated routes
• explain the first-run approval page and Tailscale's automatic HTTPS certificate and policy setup
• keep manual Add Funnel to policy steps only as a fallback
• use the Funnel-specific status command and the current BlueBubbles custom-URL label
• update the Tailscale reference links to their current documentation locations

Why

The guide was written for an older Tailscale workflow. It required users to configure certificates and the Funnel policy before running the CLI, started both Serve and Funnel on the same public port, and then checked Serve status. Current Tailscale versions configure the certificate and default Funnel node attribute during first-run approval, and Funnel has its own persistent background and status commands.

The root cause is upstream CLI and admin-console evolution since the guide was authored.

User impact

Users now have one command to expose BlueBubbles, see the approval step where it actually occurs, and verify the public route with the matching Funnel status command. Users migrating from the older guide are told how to inspect existing Serve and Funnel state without removing unrelated routes. The manual policy path remains available when automatic approval fails without making every user edit access controls up front.

Validation

• git diff --check
• verified funnel --bg, --https, and funnel status against the locally installed Tailscale 1.98.9 CLI
• compared approval, certificate, policy, supported-port, persistence, and status behavior with Tailscale's current Funnel and CLI documentation
• confirmed all ten links in the guide return HTTP 200
• confirmed BlueBubbles origin/development still uses port 1234 by default and labels the option Dynamic DNS / Custom URL
• passed a live route test: a temporary fixed-text endpoint on loopback port 1234 was exposed with the documented HTTPS Funnel command, and the exact marker was received through the public route
• confirmed Funnel status reported the temporary port 443 route while active
• removed only the temporary route, stopped the marker endpoint, and confirmed Serve and Funnel returned to their original empty state

No hostname, public URL, device name, tailnet identifier, application data, or files are included in the validation record.

Limitations

• The tailnet was already authorized for Funnel, so the first-run approval page and policy change were not exercised or captured.
• The live check validated Funnel routing and cleanup with a temporary marker endpoint; it did not run the BlueBubbles application itself.

Fixes #28

[qayshp]

Self-review focused on migration from the older Serve-plus-Funnel instructions.

[qayshp]

Validation update

• git diff --check origin/master...HEAD passes.
• The locally installed Tailscale 1.98.9 CLI recognizes funnel --bg, --https, and funnel status --json.
• The local Funnel status was readable and contained no configured routes before testing.
• The approval, certificate, policy, supported-port, and Serve-versus-Funnel behavior matches current Tailscale documentation.
• Passed live: started a temporary fixed-text HTTP marker on 127.0.0.1:1234, enabled the documented HTTPS Funnel route, and received the exact marker through the public HTTPS endpoint.
• tailscale funnel status --json reported the temporary port 443 route while it was active.
• Disabled only the temporary port 443 route, stopped the local marker, and confirmed both Serve and Funnel returned to their original empty state.

No files, application data, device name, tailnet hostname, or public URL were exposed in this validation record. This tailnet was already authorized for Funnel, so no approval page appeared and there was no approval-screen screenshot to capture.

[qayshp]

Validation supersession: the live Funnel route and cleanup now pass. A temporary fixed-text loopback endpoint was exposed with the documented HTTPS Funnel command, the exact marker was received through the public route, Funnel status showed the temporary route, and the route and endpoint were then removed. Serve and Funnel both returned to their original empty state.

This validates routing and cleanup rather than the full BlueBubbles application. The tailnet was already authorized, so the first-run approval page and policy change were not exercised. No identifying hostname, URL, device, or tailnet details are included.