docs: link the canonical home-page install anchor, not the deindexed duplicate

[worktrunk-bot]

The FAQ's Windows section and the Claude Code hook wrapper both point at https://worktrunk.dev/worktrunk/#install, a route the home page itself declares non-canonical: worktrunk.md carries rel=canonical to / plus robots: noindex, and astro.config.mjs excludes /worktrunk/ from the sitemap. Both links now name /#install, the canonical home-page anchor that docs/src/pages/index.astro renders. All three came in together with the Astro rebuild (#3866), so this is migration fallout rather than a deliberate target.

Making the primary say /#install required widening the mirror generator: SITE_LINK_PATTERN demanded a page segment (/([^)/]+)/), so a page-less site-root link matched nothing, survived the rewrite, and tripped assert_no_untransformed_site_links. The page segment is now optional, and the two identical rewrite closures collapse into one rewrite_site_links so the shape lives in one place. A slash-less ](/page) still matches nothing and still trips the guardrail.

Verified with cargo test --test integration readme_sync (19 passed) and pre-commit run over the changed files. test_site_root_links_rewrite_to_the_canonical_url is the regression test — reverting just the regex to its old shape fails it on the first assertion.

Surfaces touched

docs/src/content/docs/faq.md is the primary; skills/worktrunk/reference/faq.md, plugins/worktrunk/skills/worktrunk/reference/faq.md, and docs/public/faq.md (a symlink to the first mirror) were regenerated by test_docs_are_in_sync, which passes on the second run. plugins/worktrunk/hooks/wt.sh is hand-written and carries the URL in a runtime error message, so it was edited directly.

Found by the nightly rolling survey — an anchor-validation pass over docs/src/content/docs/ flagged this as the only broken-or-non-canonical internal link across the site.

[worktrunk-bot]

This duplicates #4000. That PR (yours, opened ~7 hours earlier) already makes the byte-identical edit to all four non-test files here — docs/src/content/docs/faq.md, both skills/.../reference/faq.md mirrors, and the error string in plugins/worktrunk/hooks/wt.sh — and widens SITE_LINK_PATTERN the same way, hoisting the two closures into a shared helper (expand_site_link there, rewrite_site_links here). #4000 also carries the piece this PR can't see the need for: docs/src/site-navigation.mjs gains { label: 'Install', link: '/#install' }, which is what makes the widened pattern load-bearing beyond the one FAQ link.

The nightly survey that opened this evidently didn't check open PRs before writing the fix. My recommendation is to close this one — but there is one thing worth salvaging first.

#4000 adds no test for the widened regex. The only new test in this PR, test_site_root_links_rewrite_to_the_canonical_url, is the regression pin for the change, and #4000's readme_sync.rs hunks add nothing equivalent. It transfers to #4000 unmodified: I traced all four assertions against #4000's (?:([^)/#]+)/)? and they hold, including the negative case [hooks](/hook) staying unmatched.

The one substantive difference between the two regexes is that character class — #4000 excludes # from the page segment, this PR doesn't. They diverge only on a malformed segment like ](/a#b/), which this PR would rewrite and #4000 would route to assert_no_untransformed_site_links. #4000's is the stricter and better one; nothing here depends on the looser class.

What I verified

Everything the description claims checks out:

• docs/src/content/docs/worktrunk.md frontmatter carries rel=canonical → https://worktrunk.dev/ and robots: noindex; docs/astro.config.mjs filters ${site}/worktrunk/ out of the sitemap. So /worktrunk/#install really was the deindexed route.
• ## Install exists in worktrunk.md (line 120), which docs/src/pages/index.astro renders at /, so /#install resolves.
• git grep 'worktrunk\.dev/worktrunk/\|](/worktrunk/' returns nothing — the sweep is complete.
• cargo test --test integration readme_sync — 19 passed, including the new test.

On the regex widening specifically: the new-match set is exactly ](/) and ](/#anchor), because skipping the optional group forces the tail to be ) or #…) immediately. It admits nothing else, and ](/page) still falls through to the guardrail. Worth noting it also closes a pre-existing hole in the other direction — UNTRANSFORMED_SITE_LINK_PATTERN's [^)]+ requires at least one character, so a bare ](/) was invisible to both the rewrite and the guardrail before this.

plugins/worktrunk/hooks/wt.sh is on the hold-for-human list in this repo's review reference, since it's the dispatcher the WorktreeRemove hook shells out to. I'm naming it for the record rather than requesting a second opinion on it: the edit is a URL inside a >&2 string in a Windows-Terminal branch that immediately exit 1s, it can't reach the removal dispatch, and #4000 makes the same edit. No approval either way — this is a self-authored PR.

[worktrunk-bot]

Closing as a duplicate of #4000, per my review above. #4000 (opened ~7 hours earlier) makes the byte-identical edits to all four non-test files here — docs/src/content/docs/faq.md, both skills/.../reference/faq.md mirrors, and the error string in plugins/worktrunk/hooks/wt.sh — and widens SITE_LINK_PATTERN the same way, with a stricter page-segment class ([^)/#]+ vs [^)/]+ here). Nothing in this branch is worth keeping over that one.

The nightly survey that opened this didn't check open PRs before writing the fix; that's the thing to correct, not the code.

I've carried the one salvageable piece — the regression test — over to #4000 as a comment, adapted to its expand_site_link helper and verified against its head. My review overstated the gap it fills: #4000's widening is already pinned indirectly by test_docs_are_in_sync, and the test's real value is decoupling that pin from the one FAQ line plus covering the bare ](/) form. Details in that comment.