v0.1.2

Three fixes, all of them for failures that said nothing while they happened.

A device whose deployment was re-keyed can enroll again. subscribe() does not
replace a subscription created under a different VAPID key; it throws
InvalidStateError. So a phone that had enrolled against an older keypair could
never enroll again from the page, however many times its owner tapped the button,
and the only remaining fix was deleting the installed web app. The enrollment page
now reads the key the browser is holding, drops the subscription when it does not
match, and falls back to unsubscribing on the throw where the browser will not
expose it. It deliberately does not unsubscribe whenever it is unsure:
re-subscribing mints a fresh endpoint, so guessing would re-enroll healthy devices
and orphan their rows.

kukuroo init --no-deploy no longer creates a Worker. wrangler secret bulk
against a Worker that does not exist creates it, and the secret upload ran before
the deploy check. A run told to stop before going live therefore put a script on
your Cloudflare account, holding real secrets, with its workers.dev hostname
claimed. The upload now waits for the deploy, and the keys are written to disk
only. Finish such a setup with npx wrangler deploy followed by npx kukuroo init --resume. The read that refuses to generate a second VAPID key for a Worker
already holding one still runs.

GET <prefix>/public-key names the variable it is missing. An unset
KUKUROO_VAPID_PRIVATE was reported as "the VAPID key on this Worker is not
usable", which is also what a corrupt key says, so an operator could not tell a
skipped setup step from a broken one. It now names the variable, the same as
/push/send already did. This is the worse of the two routes to be vague on: the
enrollment page fetches it, so the mistake surfaces on somebody's phone first.

Upgrading is npm install kukuroo@0.1.2 and a deploy. Nothing re-enrolls, and no
keys change.