ci(links): fix the stale lychee config key that kept the check disabled

Re-arming check-links surfaced why it was commented out in the first
place: lychee rejects the config outright — `follow_redirects` is not a
recognized key in the version the action pins, so the job died before
checking a single link. Replaced with `max_redirects` (lychee follows
redirects by default; this caps the chain).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: os-zhuang

lychee.toml

@@ -5,20 +5,23 @@
 # Maximum number of concurrent requests
 max_concurrency = 10
 
-# Accept status codes (2xx = success)
-accept = [200, 204, 206, 301, 302, 307, 308, 429]
+# Accept status codes (2xx = success). Strings, per lychee's config schema.
+accept = ["200", "204", "206", "301", "302", "307", "308", "429"]
 
 # Timeout for requests (in seconds)
 timeout = 30
 
 # Retry failed requests
 max_retries = 2
 
-# Follow redirects
-follow_redirects = true
+# Follow redirects (lychee follows by default; this caps the chain)
+max_redirects = 5
 
-# Check anchors/fragments in links
-include_fragments = false
+# Fragment checking is intentionally left at lychee's default (off). The
+# generated reference pages link to section anchors that only exist once MDX is
+# rendered, so checking fragments against the source files would report every
+# one of them as broken. (`include_fragments` takes a string like "full" in
+# lychee ≥0.24 — the old boolean form is what silently broke this config.)
 
 # Verbose output
 # Accepts log level: "error", "warn", "info", "debug", "trace"