feat: support path-prefix canonical base URLs in --canonical-origin

[philip]

--canonical-origin previously accepted only an origin, so it worked when production and preview shared the same path structure. But when production docs live under a path prefix (e.g. https://example.com/docs) and the preview serves from a different base, an origin swap produces broken URLs.

This PR lets the flag accept an origin plus a path prefix. When a prefix is given, matching URLs in fetched content are rewritten to the full target base instead of just swapping origins.

Along the way this fixes two latent issues in the canonical-origin rewrite itself: a $ in the target URL was interpreted as a replacement pattern, and URLs ending at ?, #, ), or , (markdown links, prose) weren't matched. The canonical value is also normalized consistently now (trailing slashes, host case, default ports).

Verified end to end against a real deploy: a Vercel preview of neon.com/docs scored identically to production with --canonical-origin https://neon.com/docs.

🤖 Generated with Claude Code

[dacharyc]

Hey, thanks for the PR Philip! This is a good enhancement, and I appreciate that it fixes a divergence we had between the CLI (which reduced the flag to .origin) and direct createContext() callers (which passed the raw value into the rewrite regex). It's nice that the CLI and API behave identically now and that was a miss on my part before this PR, so I appreciate the fix.

I did push one follow-up commit (9ebdac8) with two additions found while reviewing:

1. Sitemap <loc> entries ending exactly at the canonical base didn't rewrite. The boundary lookahead didn't include <, so <loc>https://prod.example.com/docs</loc> (the docs landing page, no trailing slash) kept its production URL while /docs/ and /docs/guide rewrote fine. In path-prefix mode, almost every sitemap has such an entry, and the leaked URL either gets filtered from discovery as external or fetched against production. Since a literal < can never appear in a valid URL, adding it to the lookahead is unambiguous. Added a sitemap-shaped test alongside your boundary tests.

2. A warning for prefix overlap. The new mode permits same-origin rewriting, and when the canonical base is a path-prefix of the target base itself (previews served under the production docs path), URLs in content that already point at the target get re-prefixed: /docs/preview-123/guide becomes /docs/preview-123/preview-123/guide. That ambiguity is inherent to prefix rewriting, so the CLI now warns without disabling the flag, and the docs mention the caveat.