Design an observability guide for transports and plugins

[TDanks2000]

Background:
api-core supports both plugins and custom transports, which gives wrapper
authors multiple places to add logging, tracing, timing, and request metadata.
The project would benefit from a design-oriented guide that explains where each
kind of observability concern belongs.

Proposed change:
Draft a guide that compares plugin-based instrumentation with transport-level
instrumentation, using supported APIs and avoiding new public runtime API unless
the design discussion identifies a clear gap.

Acceptance criteria:

• The guide explains what belongs in a plugin versus a transport.
• The guide includes one timing plugin example.
• The guide includes one tracing transport or custom fetch example.
• The guide calls out privacy considerations for logging headers and bodies.
• Any proposed runtime API changes are separated into a follow-up design issue.

Files likely involved:

• docs/guides/plugins.md
• docs/guides/testing.md
• docs/examples.md
• src/plugin/types.ts for source reference only
• src/transport/types.ts for source reference only