lockdocs 0.5.0

• First-use fetch no longer depends on GitHub's REST API quota. Upstream docs are found with git ls-remote-style tag lookups and read from one streamed codeload.github.com tarball per repository, filtered to docs paths, instead of the REST tree and per-file requests (60 per hour per IP anonymously; 2 of 10 benchmark projects failed in our clean-quota run, up to 6 of 10 behind a shared IP). Cold-cache, no token: 10/10 on the 10-question version set, no 403, 1-5 GitHub connections per project instead of 2-28. upstream::FORMAT is 5. A missing tag error lists the tag names tried. An archive over 150 MB compressed for explicit fetch, or 64 MB for the automatic first-use fetch (or a codeload failure, or too little of the automatic 45 s budget left), falls back to the per-file REST path for that repository only, and the manifest records via: codeload or rest. Measured (cold cache, no token, 1 s pacing between GitHub connections, same 10-question set): before 8/10 correct, 2 projects hit 403, 152 GitHub connections (34 REST, 118 raw), 145 s total fetch time, 1.8 MB down; after 10/10, 0 403s, 31 connections (17 codeload, none REST or raw), 27 s, 56 MB down. Per package, next 14.2.35 and 15.1.0 download a 42-46 MB tarball in 2.7-5 s and TypeScript 5.6.3 a 32 MB one in 8 s, each over 2 connections, all through codeload. Explicit docs-site fetches also download whole-repository tarballs. GITHUB_TOKEN/GH_TOKEN stays on api.github.com for explicit fetch only, as in 0.4.0; git, codeload and raw requests carry no credential, so a private repository fails with "private repository: not supported". Caches of format 4 stay usable by automatic and offline queries (an explicit fetch still refreshes them). Trade-off: bytes go up (the tarball holds the whole repository) while connections and quota use go down.