fix(parser): collapse a leading // in sanitizeUrl

[eeshsaxena]

sanitizeUrl collapses accidental double slashes, but it can't touch a leading //:

sanitizeUrl('//docs//guide/')  // -> '//docs/guide/'   (docstring says '/docs/guide/')

The regex /([^:])\/\/+/g only matches a slash-run that has a non-colon character in front of it, so a run at the very start of the string is never collapsed.

That leading // is not harmless. In a workspace build, buildAbsoluteUrl normalises an empty base to / and combines it with an absolute project path such as /search, producing //search/. A browser reads a leading // as a protocol-relative URL, i.e. //host/path, so the project-switcher link resolves against a different host:

new URL('//search/', 'https://example.com/docs/').href
// -> 'https://search/'   (not the intended 'https://example.com/search/')

There's actually a test in tests/cli-contracts/asset-base-url.test.js that already captured this //search/ output and rationalised it as "equivalent to /search/ in absolute terms" — but it isn't; //search/ points at the host search. Its assertion used /\/search\/$/, which passes for both forms, so the broken link slipped through.

The fix collapses every run of slashes and only preserves a genuine leading scheme:// separator (https://, ws://, ...). I also fixed the misleading comment in that test and tightened its assertion to require an exact /search/.

Verification:

• packages/parser/test/sanitize-url.test.js — new unit test (leading //, interior/trailing runs, scheme:// preservation, and the new URL(...) cross-host resolution). It fails on main and passes with the change.
• The resolveHref documented examples and a 300k-iteration fuzz of the href/nav helpers are unchanged (no new crashes, no altered outputs).