This PR implements the KV api by:

1. pulling down the cloudflare openapi spec, filtering for the KV subset we need (using filter-openapi.ts, with config in openapi-filter-config-ts).
2. generating types and zod schemas using hey-api (in local-explorer/generated)
3. Using hono to route and validate incoming requests

By commit:

rename getLocalExplorerFromEnv() to getLocalExplorerEnabledFromEnv() - a stray fixup from the last PR

Add resource ID to binding name map - since we route by resource id, but the id is not available at runtime, pass in an id to binding name map as a JSON binding

Add script to filter openapi spec down - takes the existing cloudflare openapi spec which is a casual 400k lines and filters it down to just the endpoints we want, and also filters out specific components we have not yet implemented.

This is done via our own parsing script rather than a library because all openapi filtering tools i can find assume that you can annotate the original openapi spec (e.g. with x-ignore). i don't think it would be practical for us to checkout and modify the full openapi spec (again, 400k lines), so instead we have this filtering script. Claude wrote this filtering script, and i've sanity checked it, but tbh i think the best way to review this is to look at the output in openapi.local.json and verify that it is what you expect. The filtering script is configured in openapi-filter-config.ts which makes it easier to extend in the future.
Once we have an openapi spec, we generate zod schemas/types using hey-api. These are in the local-explorer/generated folder.

add implementation for KV API - we use hono to do the routing here, using its middleware to validate the requests using the generated zod schemas.

I've changed the approach since #12075 because I think it will be more maintainable to start from the existing OpenAPI spec (as much as i like the concept of writing the schema in typescript, it doesn't really make sense). Also, the existing openapi spec will not undergo breaking changes without a lot of warning, so given we periodically update this spec, we should always have a compatible subset of the remote APIs. I think it is fine if we have missing APIs, because adding APIs later is a non-breaking change.

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: experimental wip thing

A picture of a cute animal (not mandatory, but encouraged)