fix(tunnel): warn before invalidating active quick tunnel URL

[bussyjd]

Summary

obol stack down and obol tunnel restart both rotate the *.trycloudflare.com URL on quick tunnels (cluster delete kills the cloudflared pod; rollout restart starts a fresh one). Until now there was no warning before the rotation, so anyone with a seller registered against the URL would silently 530 after an RC upgrade or restart cycle.

Surfaced in the rc8 reviewer feedback (item #4):

Quick-tunnel *.trycloudflare.com URLs are ephemeral and the cloudflared deployment is recreated during obol stack up. Our pre-upgrade URL result-tactics-nyc-pittsburgh.trycloudflare.com died and was replaced by hospital-binding-centered-fact.trycloudflare.com. […] anyone who previously bookmarked the old URL is now seeing 530s.

Approach

• New ConfirmQuickTunnelLoss(cfg, u, currentURL, action) in internal/tunnel. Skips when loadTunnelState shows a persistent DNS tunnel (URL is stable across cluster recreates) or when no active quick tunnel URL is captured. Otherwise warns and prompts.
• Wired into stack.Down() before the cluster-delete path, and into tunnel.Restart() before the rollout-restart.
• Non-interactive sessions (CI, JSON output, no TTY) print the warning but pass through the default (yes), so automation is unaffected.
• Drive-by gofmt of unrelated indentation drift in CreateStorefront that the formatter caught while editing the same file.

Behavior

Scenario	Result
Persistent (DNS) tunnel configured	No warning, proceed
No active quick tunnel pod	No warning, proceed (best-effort)
Active quick tunnel + interactive TTY	Warn + Continue? [Y/n] (Enter = yes)
Active quick tunnel + non-interactive	Warning printed, proceed without prompt

Sample output (interactive):

==> Stopping the Obol Stack
  ! Quick tunnel URL will be invalidated: https://hospital-binding-centered-fact.trycloudflare.com
  After `obol stack down`, the next `obol sell http` brings up a fresh URL.
  Buyers using the old URL will see 530 errors.
  For a permanent URL: obol tunnel login --hostname stack.example.com
Continue? [Y/n]

Test plan

• go build ./... clean
• go test ./internal/tunnel/ ./internal/stack/ pass
• New unit tests in tunnel_lifecycle_test.go:
  • TestConfirmQuickTunnelLoss_PersistentSkipsWarning — DNS state set, helper short-circuits to true
  • TestConfirmQuickTunnelLoss_EmptyURLSkips — no captured URL, helper short-circuits to true
  • TestConfirmQuickTunnelLoss_NonInteractivePassesThrough — warning printed, default-yes pass-through
• Manual: obol stack up → obol sell http demo → obol stack down shows the warning with the active quick URL
  • Verified on spark2; warning printed with active quick tunnel URL https://surrounded-lucia-gulf-rapids.trycloudflare.com
• Manual: obol tunnel restart on a quick tunnel shows the warning
  • Verified on spark2; restart warned before rotating the active quick-tunnel URL
• Manual: obol tunnel login --hostname … followed by obol stack down shows no warning (persistent path)
  • Verified on spark1; obol tunnel login --hostname pr424-20260505163420-spark1.humanresearch.ai completed, and subsequent obol stack down completed without the quick-tunnel invalidation warning
• Manual: piping obol stack down < /dev/null does not block
  • Verified on spark2; command completed and tore down the stack without hanging

Out of scope

• The reviewer's alternative suggestion ("skip recreating the cloudflared deployment if values are unchanged") would require the cluster to survive across upgrades, which is a much larger architectural shift. This PR addresses only the user-facing surprise.
• No on-chain re-registration on URL rotation — the existing tunnel.Restart / SyncAgentBaseURL / SyncTunnelConfigMap path already updates /skill.md and agent metadata to the new URL.