fix(navigation): ignore unknown query parameters on Buzz links and remove the buzz://open locator

[matt2e]

Summary

Third deep-links slice: three commits on top of main at 5d2b08e.

• Ignore unknown query parameters on Buzz links (ed16fc2). buzz://message keeps only channel, id and thread; the channel forms ignore the whole query; entity hosts keep only their per-type keys, so commit on a project or tab on a PR/issue is dropped too. A duplicated known key such as channel=a&channel=b is still ambiguous and rejects. This matches the original Buzz desktop client's lax message-link handling. Credentials, port, fragment, the length cap and the lowercase scheme requirement are unchanged. Everything rebuilt from a parsed link (entityHref, Copy link, the browser address) already emits the canonical form.
• Pin the project commit-hash drop (40c32b4). Test-only: buzz://project?…&tab=commits&commit=<hash> parses to the commits section with no hash, and entityHref of the result is the canonical project link.
• Remove the buzz://open?target= locator codec (fbc3c57). SharedTarget, parseSharedTarget, bindSharedTarget, targetLink, parseTargetLink and the shared link format are deleted, with no shim or flag. parseBuzzLink returns null for buzz://open, so it is plain text in message content and the OS ingress fails it as invalid-target through the same null check as any other unknown host. The original Buzz client never had this form: it was introduced in Add navigation history and preserve Messages sidebar on return #18, refused at the OS boundary in feat(desktop): add Buzz deep links and read-only entity destinations #208, and is now removed. The #buzz= browser address, parseOpenTarget and browser-history.ts share the JSON target shape, not the URL codec, and are untouched. Link Lab demonstrates the same in-app links with buzz://channel and buzz://message samples; docs/deep-links.md, docs/plugin-architecture.md and the Link Lab README now describe unknown hosts as rejected everywhere rather than "in-app only".

Behaviour change

• Buzz links that another client decorated with extra query parameters now open instead of failing.
• Existing in-app buzz://open links in old messages stop opening and lose their preview and channel label.
• @buzz/author no longer exports the SharedTarget type. No in-repo plugin imported it.

Verification

• tsc --noEmit, pnpm lint and pnpm check are clean.
• Full Vitest suite: 455 files, 5578 tests passed.
• Chromium journeys tests/browser/buzz-links.spec.mjs and tests/browser/entity-destinations.spec.mjs: 5 passed.
• One negative test per parser layer pins the removal with a literal buzz://open?target=… string: parseBuzzLink returns null, deepLinkStep fails invalid-target, messageLinkParts leaves it as plain text, and InlineLink renders it as text.
• A grep of src/, tests/, docs/ and the README finds buzz://open only in those negative tests.

Known follow-up

Open #401 adds a test in src/app/entity-navigation.test.tsx that calls bindSharedTarget(parseTargetLink(targetLink(…))). It will conflict with this branch and needs rewriting against parseOpenTarget, whichever lands second.

🤖 Generated with Claude Code

[wesbillman]

No actionable findings in the unknown-parameter handling or locator removal; the supported links still bind through the existing navigation admission path, and retired locators become inert. Star Lord automated source review via Wes’s account: head fbc3c57f055641664c527e72365679dc8a7c30d9, base 5d2b08e2ff3bb40dc62f04015298ff319f4a4f8a. No tests or app execution; hosted CI was still running at the snapshot, and packaged deep-link delivery plus keyboard/focus recovery remain unverified.

[kalvinnchau]

🤖 [P3] Distinguish unknown hosts from supported entity links

After listing only the channel/message forms, this passage says any other buzz:// host is rejected everywhere and stays plain text. Supported buzz://repo, buzz://project, buzz://pr, and buzz://issue links still pass through parseBuzzLink and are linkified/routed. For example, messageLinkParts("buzz://repo?owner=<valid-hex-owner>&d=r") returns a link part; the existing InlineLink test also expects repo links to have kind buzz.

Please use “any unknown buzz:// host” (as in docs/deep-links.md) or reference the full accepted-forms list so plugin authors are not told supported entity links are inert. The same wording needs correction in src/bundled/link-lab/README.md:35–37.