Tighten broken-link detection so internal 404s actually fail CI

[drmowinckels]

Background

PR #572 fixed a 404 link to the rebranding announcement that was introduced in PR #564. The link slipped through CI because of two limitations in the current link-check setup (`.github/workflows/lighthouse.yaml`):

1. Absolute URLs are checked against production, not the PR build. The lychee step uses `--base public` so root-relative links resolve against the PR's built site — but the broken link was written as `https://rladies.org/about-us/news/2025/announcement/\`, which lychee fetches over HTTP from the live site. At the time PR Init announcement post on new visual identity #564 ran, production still served (or redirected) the old path, so lychee posted ✅ "No broken links found."
2. `fail: false` means the check never blocks. Even if lychee had flagged the link, the workflow would still pass. It only posts a comment.

Proposed changes

Option A — Block on internal failures. Flip `fail: false` → `fail: true` in the lychee step. Combined with the existing exclusions for flaky external sites (Meetup, LinkedIn, Twitter/X, etc.), this makes broken local links a hard fail without blocking on third-party flakiness. May need to expand the exclude list once we see what shows up in practice.

Option B — Lint absolute self-links in `content/`. Add a check that flags `https://rladies.org/...\` URLs inside `content/` and asks for root-relative paths. This both matches the existing site convention (see `content/news/2025/03-14_rebranding-announcement/index.en.md` using `/about-us/mission/` etc.) and ensures lychee can verify the link locally.

The two options are complementary — A makes failures real, B prevents the specific shape of bug that caused #572.

Acceptance

• Lychee fails CI when an internal link 404s on the PR build
• (Optional) Pre-commit / CI check rejects `https://rladies.org/...\` in `content/` with a fix suggestion

Related: #572, #564