No browser chosen, no "Open on" button

The plain address is the one thing that button must not offer -- followed
in the browser the rewrite rules are installed in, it comes straight back
here -- so there is nothing to show until there is a browser to hand it to.
The copy button and the selectable URL were always the part carrying the
weight; the open link now ships hidden and the script reveals it along with
the scheme.

That also settles what the button should say. It went back to "Open on
<platform>": the browser's name was there to explain a tap that went
nowhere, and a button that is not shown until it works needs no such
explanation.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01KF5YF3iZVKbezwALap8LYd

README.md

@@ -95,11 +95,12 @@ which is the browser being escaped. The choice is kept in that browser's own
 `localStorage` — not a cookie and not synced, because "which browser is installed" is a
 fact about the device, not about you, and the phone's answer is not the Mac's.
 
-The link in the page is always the plain `https://` address, and the scheme is swapped in
-by the script afterwards; with JavaScript off, or with the default left alone, nothing
-changes. Once a browser is chosen the button says which one, because a scheme for a
-browser that isn't installed opens nothing at all, and a silent tap needs an
-explanation. The URL underneath stays selectable either way.
+Until a browser is chosen there is no "Open on …" button at all — the plain address is
+the one thing it must not offer, since following it only comes back here. The markup
+carries that address anyway, hidden, and the script swaps in the scheme and reveals the
+button once there is somewhere to send it. So with JavaScript off, or with the default
+left alone, the copy button and the selectable URL are the whole of it, which is all
+that was ever load-bearing.
 
 ## How it works