fix(playground-url): carry the share link payload in the URL fragment

[joshunrau]

Problem

Opening a share link for a large instrument on playground.opendatacapture.org fails with 431 Request Header Fields Too Large. The lz-string payload was in the query string, which is sent to the server in the request line and exceeds http-server's header limit (~16 KB).

Fix

• @opendatacapture/playground-url: encodeShareURL now writes #files=…&label=…&fullscreen=1. The fragment is never sent to the server, so link size is no longer bound by server header limits (only by browser URL limits, ~2 MB in Chrome). decodeShareURL and isFullscreenShareURL fall back to the query string when the fragment has no files, so previously shared ?files= links keep working.
• apps/playground: a link that differs only in its fragment does not reload the page, so IndexPage now reads the URL through a new useLocationHref hook that re-renders on hashchange. Without it, pasting a second share link into an open tab does nothing.
• README and both AGENTS.md files updated.

Note: links generated by this version will not load on a playground deployment that predates it (old deployments only read the query string), so the playground should be deployed alongside the package release.

Testing

• Unit (playground-url): payload lands in the fragment with an empty query string; an instrument larger than a server header limit round-trips; legacy query-string links still decode, including fullscreen.
• Manual, against the playground dev server:
  • a ~100 KB link in the old query format returns 431; in the new format the server returns 200 and the instrument loads and compiles
  • a legacy ?files= link loads
  • swapping in a second link in the same tab loads it without a page reload (and does not with the previous IndexPage)
• pnpm lint and pnpm test pass.
• No e2e test: the Playwright suite in testing/ does not start the playground, and adding it was out of scope for this fix.

🤖 Generated with Claude Code