fix(watches): confirm third-party notify addresses; harden token parsing

[Aswinmcw]

Two fixes from a review pass. Stacked on #13 — base is feat/auth-broker-migration, so this diff shows only the two fix commits. GitHub will retarget it to main once #13 merges.

---

1. A watch could email any address, with no consent from the recipient

POST /api/watches took email from the request body and activated the watch on the spot — createWatch() then confirmWatch() back to back. PATCH /api/watches/[id] could repoint an existing watch the same way. Nothing checked that the recipient wanted mail from us.

Signup is open by default (emailAllowedForSite fails open to public when ACCESS_MODE is unset), so one verified account was the entire cost of entry. From there: register watches against a victim's address and generate mail from our Resend domain — a "watch created" notice immediately, then one per status change, indefinitely. Also a deliverability problem, since those land as unsolicited mail under our sending identity.

Now:

notify address	behaviour
the account's own	activates immediately, as before
anyone else's	watch parks at pending + confirmation link emailed

The poller only reads status='active', so an unconfirmed watch sends nothing. PATCH follows the same rule — repointing at a third party sends the watch back to pending; moving it back to your own address releases it. Cancelled/completed watches can't be revived by an edit (the status update is scoped to in-flight rows).

This revives /api/watches/confirm and confirmEmail(), both of which were already in the tree and orphaned when the double opt-in was dropped — that was review item #2, closed by the same change.

The ADMIN_TOKEN curl path is deliberately unchanged: that token is the operator's own credential, not something a signup can obtain.

Also caps an account at 50 in-flight watches (429 watch_limit_reached), bounding both the mail one account can generate and its share of the poller's 50-per-tick budget.

2. Malformed tokens returned 500 instead of "invalid link"

In src/lib/tokens.ts, b64urlDecode(sig) sat outside the try/catch, so atob() threw a DOMException on any signature that isn't valid base64url — a link a mail client wrapped or truncated came back as a 500 rather than the "This link is no longer valid" page the route already renders. The extracted @aswincloud/auth copy of this file guards the decode; ours had drifted.

---

Verification

Against a local D1 + dev server, with Resend pointed at an invalid key so nothing could actually be sent:

own address           → 201 {status:"active"}, row active
third-party address   → row never reaches 'active'
pending row           → excluded from the poller's due-query
confirm link clicked  → row flips to active
PATCH → third party   → row parked at 'pending'
PATCH label only      → stays active
51st watch            → 429 watch_limit_reached

Token parsing, before → after on the running route:

token=abc.!!!!  HTTP 500 → HTTP 400
token=%%%.%%%   HTTP 500 → HTTP 400
token=garbage   HTTP 400 → HTTP 400   (no ".", rejected earlier)

Plus a table of valid/expired/wrong-purpose/wrong-secret/malformed cases run against the real file: 4 malformed inputs threw DOMException before, all return null after. tsc --noEmit passes.

Worth knowing

• If the confirmation email fails to send, POST cancels the just-created watch (it could never be confirmed, and a dead row shouldn't count against the cap) and returns 502. On PATCH the watch stays parked at pending with the new address — no alerts go anywhere, and re-saving your own address reactivates it.
• Unconfirmed watches are never purged, so they sit against a user's cap until cancelled. Fine at a 50 ceiling; a sweep for stale pending rows would be the tidier long-term answer.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	shiptrack-poller	b0deeb4	Aug 14 2026, 09:58 AM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	shiptrack	b0deeb4	Aug 14 2026, 09:58 AM

[Aswincloud-Bot]

Auto-approved: @Aswinmcw is a member of @Aswincloud/admins.