0.9.1 — the phone link points where you chose, Cloudflare has a setup wizard, and the usage chip comes back

Mostly fixes, and two of them were things Stoke was doing to itself.

• The transport is a choice again. Saving a hostname used to pin the "Reach
  it from" picker to Cloudflare Tunnel permanently — the other two segments lit
  nothing when pressed — because a three-way choice was inferred from two
  booleans plus a non-empty string. Worse, the link followed the same rule: with
  a hostname saved and no tunnel running, the QR code encoded https://<host>/
  while the server listened on your LAN, so it pointed at a name nothing served.
  There is an explicit preference now; the binds mean only what the socket
  listens on. A running tunnel still wins over everything, because that is a
  fact about now rather than about a config file.

• Setting up a Cloudflare Tunnel is five steps that say where you are stuck,
  instead of a box printing four commands. Each step reports what it found, runs
  itself where that is possible, and quotes cloudflared rather than paraphrasing
  when it fails. What each step can detect is not uniform and the panel says so:
  install and login are local facts, whether the tunnel exists is a live API
  call and so has a third answer — "could not ask" — and the DNS route cannot be
  read back at all.

• Error 1033 gets named where you can see it. tunnel route dns refuses to
  overwrite an existing record, so a hostname that ever pointed anywhere keeps
  pointing there while Stoke runs a different tunnel and draws a QR code for the
  name. The panel now says so beside the code, with the remedy, and "Replace the
  existing record" is offered on the first attempt rather than only after a
  failure. It also says that a Cloudflare Access policy is a separate layer and
  not the cause — turning Access off would expose the hostname and change
  nothing about the 1033.

• A restarted tunnel no longer orphans the old one. cloudflared shuts down
  gracefully on SIGTERM, draining for up to its grace period, so a restart left
  two connectors serving one tunnel — and when the old one finally exited it
  cleared Stoke's handle on its replacement. The panel then said "not running"
  while it was running, Stop had nothing to kill, and quitting could not clean it
  up either.

• The chip works again with no session running. It was reading an expired
  token out of ~/.claude/.credentials.json while a live one sat in the login
  Keychain, and returning "sign-in has expired" without ever making the request.
  It compares freshness now rather than preferring a location. The 30-second
  poll was never broken — it was faithfully re-fetching the same error, which
  looks identical to not polling at all.

• A rate-limited chip says when it will try again, and stops offering a "Try
  again" button that could only return the same cached failure.

• The close button belongs to the tab, not to the end of the title. It sat
  wherever the title happened to end and moved every time Claude renamed the
  session, which is the one thing a close button must never do.
  -----BEGIN SSH SIGNATURE-----
  U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgRMU791FgMe8r+DfqyzVBFQ6kaz
  8vnoPpPI8Ui7gGH3MAAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5
  AAAAQHXMa95i49PLIIq5AN/oDAhtGzuQXJEEi/9skDDCxdtFsrNGM0iW9boKlrVO2DNEvM
  Yyfn4+EFbVcLfVsaEEDAc=
  -----END SSH SIGNATURE-----