docs: publish Sourcey API reference on GitHub Pages

[IvanchitorJR]

Why

This repository already owns a GitHub Pages deployment, but it currently publishes only coverage.html; the Pages root returns 404. The README links individual symbols to pkg.go.dev, but there is no project-owned, searchable API home or LLM context export.

What changed

• Pin Sourcey 3.6.5 as a documentation-only dependency.
• Generate reference pages from the real Go source with Sourcey's godoc adapter.
• Limit the site to the two public packages: github.com/coder/websocket and github.com/coder/websocket/wsjson.
• Publish the generated site through the existing project-owned Pages workflow while preserving coverage.html and coverage.svg.
• Normalize internal links for the /websocket/ GitHub Pages base path.
• Link the project-owned API home from the README.

Verification

• pnpm install --frozen-lockfile
• pnpm docs:build (3 HTML pages; root API, duplicate landing entry, and wsjson; plus search, sitemap, llms.txt, and llms-full.txt)
• go test ./...
• go vet ./...
• Native and GOOS=js GOARCH=wasm package compilation
• Confirmed that the rendered pages contain real signatures, comments, and examples for Accept, Dial, Conn, Read, and Write, with no unexpanded documentation directives.

A review-only mirror of the exact generated output is live at https://coder-websocket-sourcey.ivandejesus1806.chatgpt.site/. After merge, the existing workflow publishes the project-owned home at https://coder.github.io/websocket/.

No runtime code or public API changes.

[IvanchitorJR]

CI note for maintainers: the current failure is the existing WebAssembly test timing out (TestWasm: websocket url timeout reached after ~20s). The same master SHA (9c8faad) has failed the repository's daily workflow repeatedly, while this PR's docs-only diff does not touch Go runtime/test code. fmt and lint pass on the refreshed head; the failing job is https://github.com/coder/websocket/actions/runs/29354123229/job/87157385721. I cannot rerun the upstream job from the fork (GitHub returns 403), so I am leaving the evidence here rather than adding an unrelated test workaround to this documentation PR.