Add redirect link system and scope Pages publishing to its own job

[flufflycthu1u]

Posts now link to cutepetsboston.com/r/?id= rather than straight to the shelter listing, so click-through can be attributed per pet (RFC 0001). The slug -> adoption URL mapping is append-only and lives on the gh-pages branch; docs/r/index.html resolves it client-side and falls back to the homepage when a slug is unknown or the fetch fails.

Pages publishing moves into a reusable workflow, publish-pages.yml, called by both prod.yml and deploy-pages.yml:

• prod.yml splits into two jobs so the job that posts pets runs with a read-only token; only the publish job holds contents/pages/id-token write. A composite action could not do this, as it inherits the calling job's token.
• Both callers share the pages-publish concurrency group, so a docs push and the 4-hourly cron can no longer deploy Pages at the same time.
• The mapping is merged rather than copied (jq -s '.[0] * .[1]' with gh-pages winning conflicts), so a failed fetch can no longer wipe existing redirects.
• The deploy job declares environment: github-pages, which actions/deploy-pages requires and prod.yml previously lacked.

Fixes in redirects.py and the interstitial:

• a corrupt mapping no longer blocks posting; it logs and posts the raw URL, leaving the damaged file untouched rather than silently rebuilding it
• slugs are injective, so two distinct pet ids can no longer collapse onto one slug and point a post at the wrong pet's listing
• load_redirects/save_redirects resolve the default path at call time rather than binding it at import
• only http(s) targets are followed or recorded, so a javascript: URL coming from the RescueGroups API cannot execute on our own origin
• redirects.json is gitignored; the gh-pages commit therefore uses git add -f

docs/specs/redirect-pipeline.md diagrams the pipeline as built and how the planned analytics page attaches to it.