feat(extensions)!: normalize extension version and capability negotiation

User Story

As an operator or extension author, I want every supported extension protocol to negotiate version and capabilities consistently, so that incompatible gateway and extension combinations fail clearly instead of silently degrading.

Problem Statement

Compute drivers, credential drivers, gateway interceptors, and supervisor middleware expose different version and capability shapes. Some report a free-form implementation version, some provide service metadata, and some lack protocol-version negotiation. The gateway cannot apply one compatibility policy across extension families.

Impact / Why This Matters

Operators can pair independently deployed components that connect successfully but do not understand required fields or behaviors. Each extension author invents compatibility rules, and clients cannot discover which optional capabilities are supported. Silent degradation is especially risky when a missing capability affects security or resource enforcement.

Proposed Design

Define a common extension handshake model with:

• a protocol contract version distinct from the implementation/build version;
• a typed or namespaced capability set;
• required versus optional capability semantics;
• clear rejection and diagnostic behavior for incompatible peers;
• a documented gateway/extension version-skew policy; and
• capability snapshots available through appropriate operator/client discovery surfaces.

Apply the common semantics to compute drivers, credential drivers, gateway interceptors, and supervisor middleware while allowing extension-specific capability payloads.

Acceptance Criteria

• Every supported extension protocol reports protocol version and implementation version separately.
• Every protocol can advertise optional capabilities and declare required capabilities.
• The gateway rejects an extension missing a required capability with an actionable error.
• Unknown optional capabilities are tolerated according to documented forward-compatibility rules.
• Supported version skew is documented and covered by mixed-version tests.
• Operator-visible gateway information reports negotiated extension versions/capabilities without exposing secrets.
• Built-in extensions use the same negotiation path as external extensions.
• Extension author documentation and migration notes include the new handshake.

Alternatives Considered

Compare semantic implementation versions in the gateway. This requires a growing feature-to-version table and conflates build identity with protocol support. Let every extension family retain its own mechanism. This preserves current inconsistency and makes a system-wide compatibility policy unenforceable.

Agent Investigation

The current protocols expose different combinations of driver_version, service_version, manifests, and capability fields. Resource-specific compute capabilities are tracked in #2902, while fail-closed gateway/supervisor feature negotiation is tracked in #2949.

Related: #2565, #2902, #2949. Source audit: https://gist.github.com/mrunalp/e80942c1544a0225ee588796a41ab30b.