Remove ?token= deletion-token path (#143)

The deletion token was accepted via the ?token= query parameter on both
DELETE /api/pastes/{id} and /redeem, and round-tripped through the paste
URL after creation. URL-carried bearer secrets leak into reverse-proxy
access logs and browser history.

- API: deletion tokens are now accepted only via the Authorization header
  (Bearer/Token/bare); query params are ignored on both endpoints
- Web create flow: token moves to the browser via a short-lived tok_<id>
  HttpOnly cookie instead of the redirect URL; the paste view reads it
  from the cookie, never from ?token=
- Web view: the delete button calls redeem() which takes the token from
  sessionStorage and sends it as an Authorization header
- Tests: correct token in query must be rejected (403/400); header path
  still deletes/redeems; extraction unit cases updated

Fixes #143

internal/web/templates/new.html

@@ -291,7 +291,9 @@ function finishCreate(data) {
       setTimeout(() => { copyBtn.classList.remove('ok'); copyBtn.textContent = '⧉'; }, 2000);
     } catch(e) { toast('Copy failed', 'error'); }
   });
-  const dest = '/' + data.id + '?created=1&token=' + encodeURIComponent(data.deletion_token || '');
+  // token carried via sessionStorage, never in the URL (#143)
+  const dest = '/' + data.id + '?created=1';
+  try { sessionStorage.setItem('deletion_token_' + data.id, data.deletion_token || ''); } catch(e) {}
   // password-protected: unlock now with the password we already have (#26)
   if ($('haspw').checked && data.id) {
     const fd = new FormData();