Wire hosted MCP read tools into the per-workspace read limiters

[zachdunn]

Context

PR #840 (issue #829 §3) added per-workspace read rate limiting to the API worker: READ_LIMITER for normal reads and HEAVY_READ_LIMITER for expensive ones (search, facets, by-path, metadata-hydrated listings). See apps/api/src/read-limits.ts.

The hosted MCP worker was left out. It has its own binding set and request path, so its read tools (find_files, list, facets-backed tools, and similar) reach the same expensive D1 and storage reads without passing through either read limiter.

Proposed work

• Add the two read limiter bindings to the MCP worker's wrangler config (production unsafe.bindings plus the previews ratelimits block), following the pattern of its existing write limiter.
• Classify MCP read tool calls with the same tiers as the API routes. Reuse the classification helpers from apps/api/src/read-limits.ts rather than duplicating the rules.
• Surface a refusal to the MCP client as a structured tool error that includes the retry delay.
• Keep limits and windows identical to the API worker's so one workspace has one effective budget shape, even though the counters are separate per worker.

Notes

• Flagged as a deliberate skip in PR feat(api): add per-workspace read limits and consistent 429 metadata (#829) #840's summary.
• Write-path limiting on the MCP worker is unchanged and out of scope here.