In order to support multiple versions (i.e major & minor version bumps) in the extensions API, we need to propagate the major+minor version of the extension that was negotiated at load time through all calls between the Host and the Extension boundary.

As part of this ticket, introduce the concept of a CapabilityVersion made up of Extension.version.major, extension.version.minor . The negotiated CapabilityVersion (or more appropriate name) will need to be propagated through calls via Handles on the host side and adapters on the API side.

• New API surface is append-only: slots are added at the end of vtables, never reordered or
  removed.
• Version-conditional constraints: a handle only requires the vtable slots the negotiated version
  guarantees, so extensions compiled against older versions load at older capabilities and the host
  never reads past the negotiated boundary.
• Runtime guards in handle methods refuse to invoke slots the negotiated capability does not cover.
• Type-level bounds checks (isSupported on the min/max capability traits) reject wrapping a type
  at a capability outside its supported range (e.g., a type introduced in 1.2 at a 1.0 session).
• handle.h drops the compile-time kMaxSupportedCapability <= latestCapability() bound (the existing
  SR_DEBUG TODO) so handles can declare support for upcoming minors/majors — needed to simulate a
  future 2.0 without editing api.h; enforcement stays in isSupported() at runtime.