cloudflare: Several common bindings are not instrumented

Bắt đầu từ packages/cloudflare/src/instrumentations/worker/instrumentEnv.ts và so sánh đường dẫn phát hiện và instrumentation R2 hiện có. Thêm tính năng phát hiện dành riêng cho KV bằng get, put, list và getWithMetadata, đồng thời loại trừ JSRPC, sau đó instrument binding bằng các span tương ứng với instrumentR2. Hoàn thành khi các thao tác trực tiếp trên env.MY_KV được instrument mà không nhầm lẫn với các binding khác, đồng thời các bài kiểm thử instrumentation Cloudflare liên quan được cập nhật hoặc bổ sung.

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.