cloudflare: Several common bindings are not instrumented

從 packages/cloudflare/src/instrumentations/worker/instrumentEnv.ts 開始，並比較現有的 R2 偵測與插樁路徑。使用 get、put、list 和 getWithMetadata 新增 KV 專用偵測，同時排除 JSRPC，然後使用與 instrumentR2 相符的 span 對該 binding 進行插樁。完成的標準是：直接的 env.MY_KV 操作能夠被插樁而不會誤判其他 binding，且相關的 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.