Webmention display refreshes on new-mention webhook instead of a polling cron

## Summary

Replace (or complement) the 6-hour rebuild cron with an event-driven
rebuild triggered by webmention.io's webhook, so the static webmention
display refreshes only when a mention actually arrives.

## Motivation

The Pages site is static and fetches webmentions at build time, so a
post's engagement display freezes between builds. #150 added a 6-hour
`schedule:` cron to `pages.yml` to keep it current, which means most
rebuilds redeploy byte-identical output. webmention.io can fire a
webhook on each new mention; routing that into a GitHub
`repository_dispatch` rebuild would eliminate idle rebuilds entirely.

## Scope

- webmention.io's webhook can't authenticate to GitHub's dispatch API
directly (it POSTs a fixed body with no auth headers), so it needs a
small relay that holds a fine-grained PAT and translates the webhook
into a `repository_dispatch` (or `workflow_dispatch`) call — e.g. a
Cloudflare Worker.
- Add a `repository_dispatch` trigger to `pages.yml`.
- Decide whether to keep the cron as a low-frequency backstop (catch
missed webhooks) or drop it.
- Keep the relay's secret out of the repo; the public username stays
committed as IaC.

## Acceptance criteria

- [ ] A new mention at webmention.io triggers a Pages rebuild without
a content push.
- [ ] No idle rebuilds when there are no new mentions (or an explicit,
documented low-frequency backstop).
- [ ] Relay credential stored as a secret, not committed.

## Additional context

Refinement of the polling cron from #150. Related: #148
(account/IndieAuth/deploy-env setup), #144 (display), #201 (Bridgy
backfeed, the main source of new mentions). Someday — not blocking.