pickier: link-fragment slugs differ from GitHub's for em-dashes

Two warnings on PLAN.md that are false positives:

markdown/link-fragments: Link fragment '#10-upstream-fixes--at-the-source' does not match any heading
markdown/link-fragments: Link fragment '#107-stx--craft--stacks--bun-ranges-do-not-actually-pin' does not match any heading

Both anchors are correct. GitHub's slug algorithm lowercases, strips punctuation, and turns spaces into hyphens — so ## 10. Upstream fixes — at the source becomes 10-upstream-fixes--at-the-source: the em-dash is stripped and the two surrounding spaces collapse to two hyphens. That is exactly what the link says, and the links resolve on GitHub.

pickier appears to keep or otherwise handle the em-dash differently when building its expected slug.

Filed here rather than in pickier because it is only a warning and the harness side needs nothing; noting it so the next person does not "fix" correct anchors to satisfy the linter. Same rule already got its inline-code masking right in 0.1.49 (which cleared our last lint error), so the machinery is close.

Reproduce: any heading containing — with a TOC link to it.

Fixed at the source in pickier — the slug collapsed runs of whitespace where GitHub emits one hyphen per whitespace character, so anchors following a stripped em-dash or slash were reported broken. Released in pickier 0.1.50 (pickier/pickier@abc6348); harness is on it and now lints with 0 errors and 0 warnings.