Add `diagnostics_channel` support for query and connection lifecycle events

该 issue 提到了 pg 和 pg-pool，但没有实现文件或测试。首先检查现有的 IITM/RITM instrumentation 以及 undici 的 TracingChannel 模式；在实现可以被视为完成之前，具体提案必须确定 channel 名称、payload 结构以及与 Node 版本的兼容性。

I'd like to propose adding first-class TracingChannel support to pg and pg-pool, following the pattern established by undici in Node.js core.

TracingChannel is a higher-level API built on top of diagnostics_channel, specifically designed for tracing async operations. It provides structured lifecycle channels (start, end, error, asyncStart, asyncEnd) and handles async context propagation correctly, which was the missing piece that makes existing monkey-patching approaches fragile in real-world async Node.js applications.

Current instrumentation's today use IITM (import-in-the-middle) for ESM and RITM for CJS which has a few fragility concerns in today's ecosystem state, a few issues we have today:

• Runtime lock-in: both RITM and IITM rely on Node.js-specific module loader internals (Module._resolveFilename, module.register()). They don't work on Bun or Deno, which implement the Node.js API surface but not the module loader internals.
• ESM fragility: IITM is built on Node.js's module customization hooks, which are still evolving and have been a persistent source of breakage in the OTEL JS ecosystem.
• Initialization ordering: both require instrumentation to be set up before pg is first require()'d. Get the order wrong and instrumentation silently does nothing, which is very hard to debug in production.
• Bundling and Externalization: Users have to ensure their instrumented modules are externalized, which is becoming very difficult to guarantee with more and more frameworks bundling the server-side code into single executables, binaries or deployment files.

If pg emits structured events through TracingChannel, instrumentation libraries become subscribers, not patches. Each tool listens independently with no ordering concern, no clobbering, and no internal API dependency.

Before putting together a concrete proposal and PR, wanted to check: is there appetite for this? Happy to spec out channel names, payload shapes, and Node version compatibility considerations if so.