cloudflare: Several common bindings are not instrumented

Empieza en packages/cloudflare/src/instrumentations/worker/instrumentEnv.ts y compara la ruta existente de detección e instrumentación de R2. Añade una detección específica de KV mediante get, put, list y getWithMetadata, excluyendo JSRPC, y realiza la instrumentación del binding con spans que coincidan con instrumentR2. La tarea estará terminada cuando las operaciones directas de env.MY_KV estén instrumentadas sin confundir otros bindings y se hayan actualizado o añadido las pruebas de instrumentación relevantes de Cloudflare.

packages/cloudflare/src/instrumentations/worker/instrumentEnv.ts detects D1, Queue, R2, RateLimit, Workers AI, DurableObjectNamespace and JSRPC. Nothing else matches, so these fall through untouched:

Workers KV verification A live KvNamespace binding matches none of the seven duck-type checks, so instrumentEnv's proxy returns it untouched:

kvCtor: "KvNamespace", methods: [get, put, delete, list, getWithMetadata]
isJSRPC: false            hasIdFromName: false      hasSendAndSendBatch: false
hasPrepareBatchExec: false hasHeadPutMultipart: false hasLimit: false
hasRunGatewayToMarkdown: false

The same worker, one invocation, with two controls to prove the harness works:

KVNamespace and getWithMetadata appear nowhere in any package's src. Every kv match in packages/cloudflare/src is Durable Object storage (ctx.storage.kv), including the durableObjectSqlSpanAllowlist sibling option at client.ts:386 that mentions "KV reads/writes".

One exception: KV is not completely uncovered across the monorepo. @sentry/nitro and @sentry/nuxt subscribe to unstorage tracing channels (packages/nitro/src/runtime/hooks/captureStorageEvents.ts:84) and emit cache spans with db.system.name taken from the unstorage driver. A Nitro or Nuxt app on Cloudflare that reads through useStorage() over a KV-backed mount therefore does get spans. That path does not help direct env.MY_KV access, and does not exist for Next.js, TanStack Start, SvelteKit, Hono, React Router, or a plain Worker. So the gap is real, but scope any new issue to the binding rather than to "KV", and reuse the op naming that instrumentation already established.

Work item. Start with the KV binding alone: an isKVNamespace duck-type (get + put + list + getWithMetadata, and not JSRPC) plus an instrumentKV that emits spans matching instrumentR2. getWithMetadata is the discriminator worth keying on, since get/put/delete/list are common enough to risk a false positive. Order the check before isRateLimit, which matches anything with a limit method. Ship Vectorize and Analytics Engine as follow-ups.

**Prior art **(tracked). Most of this list is already tracked, one issue per binding:

Workers KV having no issue was worth double-checking, because two closed issues look like they cover it and do not: #19384 "Cloudflare Instrument Async KV Api" and #20830 "Cloudflare instrument Sync KV API" are both sub-tickets of #19106 (SQLite-backed Durable Object storage). They are about ctx.storage.kv, not the env.MY_KV binding, and both shipped. So the most-used Cloudflare binding is the one gap with no ticket, and it reads as already done.