Keep showing a guest link's URL so it can be copied again

The URL was shown once, in a box under the create button, and then gone: only
a hash of the token was stored, so the app genuinely could not produce it a
second time. Lose the message you sent the sitter and the only way back was to
mint a new link — which strands whoever is already holding the old one.

Settings now lists every live link with its URL and a Copy button, so re-sending
one is just copying it again.

That means keeping the token rather than only its hash, and it is worth being
plain about the trade. It is not the trade you would make for a password, which
the user has probably reused, or a session token, which grants everything
indefinitely. A guest link grants a strict subset of what the same database
already holds in plaintext, expires on a date the owner picked, and can be
revoked in one tap — so an attacker who can read puppy.db gains very little by
also being able to open it as a guest. The lookup column stays a hash and
remains the key redeem matches against; the secret sits in a new column beside
it, which also keeps the migration additive.

Links created before this have an empty secret. They keep working and stay
revocable — the migration touches nothing but the new column — and the list
says why their URL is missing rather than rendering a broken one.

The two tests that asserted the old contract now assert the new one: a listing
hands back a secret that really opens the link, and the lookup column is still
a hash. Added one for the legacy row, since "still works, just cannot be shown"
is the part a future change is most likely to break quietly.

README.md

@@ -169,10 +169,14 @@ Guest access** mints a link that does exactly the first thing.
   and every request re-checks that the link is still live — so revoking kicks
   whoever is already using it out on their very next request, not whenever their
   session happens to lapse. Revoking also deletes those session rows outright.
-- **The URL is shown once.** Only a hash of the token is stored, exactly as with
-  session tokens, so a leaked database yields no working links — and the app
-  cannot show you the URL again later. Settings lists each live link by label,
-  expiry and when it was last used.
+- **The URL stays available.** Settings lists each live link by label, expiry
+  and when it was last used, with the URL and a *Copy* button, so a link can be
+  re-sent without minting a new one and stranding whoever holds the old. That
+  means the token is stored, not just its hash — a deliberate trade, and not the
+  one you would make for a password or a session token: a guest link grants a
+  subset of what the same database already holds in plaintext, so whoever can
+  read `puppy.db` gains little from it, and it expires and can be revoked
+  besides. The lookup column stays a hash; the secret sits beside it.
 - **Events say who logged them.** An event created through a link carries that
   link's label (badged in the History log) and its id (which is what authorises
   changes). The server stamps both from the session on insert and never reads