Feat: Expose hooks publically to support client observability features

[rspurgeon]

Clients want to expose, from a central place, critical observability data. For example logging request/response lifecycles.

For “deeper SDK data” (not just raw HTTP), sdk-konnect-go needs a small observability surface added.

Consider:

1. Expose hooks/observers publicly.
   Today hooks are internal-only (internal/hooks/hooks.go:27), so kongctl cannot register custom SDK-aware hooks
   directly.
2. Add a public SDK option to register them.
   Something like WithHTTPObserver(...) or WithHooks(...) on the SDK constructor (sdk.go:437).
3. Expose SDK metadata in event context.
   OperationID exists internally (controlplanes.go:61), but should be passed to consumers via public event structs/
   context so logs can include SDK operation identity.
4. Add retry/attempt metadata.
   Because requests may be retried, include attempt, max_attempts, and stable request_id in hook events to correlate request/response/error cleanly.
5. Propagate metadata onto req.Context before Client.Do.
   That lets custom HTTP clients (like kongctl’s wrapper) read SDK-level fields without per-operation code.
6. Optional but useful: ship a built-in structured logging hook.
   Current env-based dump hooks (internal/hooks/registration.go:11) are stdout dumps, not level-aware structured logs
   with redaction.

That is the minimum SDK work to unlock richer fields like operation_id while keeping logging centralized.