Add Reference section for the HTTP API

[cdebled]

Summary

• Add a new reference/http-api page documenting the /api/fetch endpoint's request parameters and response shape, sourced from Lightpanda Cloud's bgw repo (api/fetch.go, api/fetch/fetch.go, api/browser.go)
• Slim usage/api.mdx down to a practical guide (connect + one example), linking to the new reference for the full parameter/response list
• Fix two inaccuracies found while syncing against bgw @ 3cbf3468 (origin/master):
  • status's type is int, not uint
  • wait_ms: 0 doesn't mean "don't wait" — it silently falls back to the same 5000ms default as omitting the field
• Confirm via live API testing (not found anywhere in bgw's own source, which has no proxy-name allow-list) that proxy_name really does default to fast_dc and country only takes effect with proxy_name: "datacenter"; both existing claims check out

This PR is part of a series splitting the new Reference section (CLI, MCP tools, HTTP API, PandaScript) into smaller pieces so each can be reviewed and merged on its own: #76 (CLI reference), #77 (MCP tools reference), #78 (PandaScript reference).

No cross-references here point at another PR's pages, so nothing needs fixing once the others merge.

[arrufat]

Verified everything against bgw at 3cbf3468, which is still master's HEAD, so no drift on this one. Both fixes check out in the handler: wait_ms is *uint with a > 0 guard so 0 really does fall back to the 5000ms default, and the response struct is Status int with Headers map[string]any and omitempty, matching the new int/object/optional wording. The raw content types (text/html / text/plain) and all defaults match too. Two small notes inline.

[arrufat]

Heads up that all four PRs in the series (#76, #77, #78, this one) create this same file with a different single key, so the last three to merge each need a small conflict resolution here, and the final key order decides the sidebar order of the Reference section.

[cdebled]

Yes, I chose to create independent PRs, all based on the main branch, so as not to constrain which one we want to merge first. But sure, I'll handle the conflicts after each merge (not a complex conflict). As for the order, I'm planning: CLI, HTTP API, MCP tools, Pandascript.