Strip tracking parameters from redirect suggestions

[dvdstelt]

Follow-up to #29, which surfaced this.

Problem

Redirect targets often carry query parameters that identify the visit rather than the content. support.google.com is the case that prompted this: following a redirect there lands on a URL carrying a visit_id session token and an rd redirect counter.

HyperHawk suggested that URL verbatim, so applying the one-click suggestion committed something like this into a markdown file:

https://support.google.com/analytics/table/13948007?visit_id=639222257369492970-241975759&rd=2

The visit_id is stale the moment it is written down. The path change is the real fix, the parameters are noise.

This weakness predates #29, but #29 made it reachable for hosts that error on HEAD, so it would have started showing up more often.

Fix

buildRedirectUrl now runs the destination through stripTrackingParams before re-attaching the fragment. Three rules:

1. Known tracking parameters are dropped: visit_id, rd, sjid, gclid/dclid/fbclid/msclkid, mc_cid/mc_eid, _ga/_gl, and anything prefixed utm_.
2. A parameter already on the original link is kept. Only what the redirect introduced is removed. The goal is to strip server noise, not to rewrite what the author deliberately wrote.
3. A tracking-only redirect produces no suggestion at all. If stripping leaves the destination equal to the original link, isSameUrl suppresses the suggestion rather than offering a no-op.

Rule 3 was not in the original scope but falls out of the same problem. example.com/x redirecting to example.com/x?visit_id=... was pure noise before, and once the parameter is stripped there is nothing left to suggest.

Verification

Against the real URL from the #29 follow-up:

URL	Before	After
support.google.com/analytics/answer/9143382	.../table/13948007?visit_id=6392...&rd=2	.../table/13948007
support.google.com/analytics/answer/11109416	ok	ok, no suggestion

Four new routes on the snapshot test server, one per rule plus the interaction with fragments:

Route	Expected
/tracked-move	-> /final, path move with all three parameters stripped
/tracking-only	ok, no suggestion
/keeps-author-param?utm_source=author	-> /final?utm_source=author, author's parameter kept, visit_id dropped
/tracked-move#my-anchor	-> /final#my-anchor, fragment survives stripping

The existing /final route had to widen from an exact string match to also match /final?..., since it would otherwise 404 once redirects started carrying query strings.

npm run typecheck and npm run test:snapshot pass. dist/ is rebuilt and verified in sync with src/.

Docs

docs/how-it-works.md is updated in both places that describe redirect suggestions.