Restore automated redirect checking in CI (removed in #3624)

Follow-up to #3672.

#3624 removed the redirect-checking workflow on 2026-07-09 because it was "always broken". Four days later, #3542 shipped a navigation restructure that reintroduced a redirect bug (#3611), which had to be caught by hand and fixed in #3629. With no CI check, the next regression ships silently.

Given the SEO cost of redirect gaps documented in #3672 (the March restructure ran without complete redirects for 10 days to 3 weeks), some form of automated check is worth having again, even a minimal one. Suggestion for a more robust approach than the old script:

1. On every PR that touches config/navigation.json, config/redirects.json, or deletes/renames any .mdx file: verify that every previously reachable page path is either still present or has a source entry in config/redirects.json. This is a pure file diff against the base branch, no HTTP calls, so it cannot be flaky.
2. Verify every redirect destination in config/redirects.json resolves to an existing .mdx page path (or another redirect source, with cycle detection). Also pure file checks.
3. Optionally, a scheduled weekly job that curls a fixed list of high-traffic legacy URLs (top ~50 from GSC) and fails on anything that does not end in a 200.

Steps 1 and 2 would have caught both the March gap and the #3542 regression without the flakiness that got the old workflow deleted.

Start by reviewing the redirect-checking workflow removed in #3624, then inspect config/navigation.json and config/redirects.json along with the changes described in #3542 and #3611. Implement checks for missing previously reachable paths, invalid destinations, and redirect cycles; verify that the checks run on relevant pull requests without HTTP calls.