[Feature]: Support multiple versions per ID across catalog types

The issue describes a major feature to support multiple versions per ID across catalog types (extensions, presets, workflows, steps, bundles, integrations). Start by understanding the existing catalog data structures in the codebase, likely in a catalog module. Review the linked issue #4712 for context on the failure. The work requires designing a backwards-compatible version-history representation, updating lookup logic, and modifying CLI commands like search, info, add, install. Separate PRs are required per catalog family, so the first step is to examine one family (e.g., extensions) and propose the new schema. Tests must cover legacy single-version entries and new multi-version lookups.

Summary

Spec Kit catalogs currently resolve an ID to one advertised version. Customer-hosted, install-allowed catalogs should be able to retain multiple approved releases of the same ID and resolve either the advertised current release or an exact historical version. The failure in https://github.com/github/spec-kit/issues/4712 is one consequence: a bundle pins a component version, but after its catalog entry advances, the older release cannot be selected even if the artifact remains available.

Distinguish capability from publishing policy: The bundled community catalogs are discovery-only, current-tip listings. They do not need to publish historical releases, and this change must not turn them into install sources. Existing first-party and customer catalogs that publish only one version must continue to work.

Desired contract and CLI behavior

• Define a backwards-compatible version-history representation for each catalog family: extensions, presets, workflows, steps, bundles, and integrations. Keep an unambiguous advertised current release and version-specific URLs, hashes, requirements, and other metadata where relevant; reject inconsistent or malformed release records. Existing single-version payloads remain valid.
• Support current-by-ID and exact-by-ID-and-version lookup while preserving catalog precedence and install policy. If the selected install-allowed source lacks a requested version, fail explicitly; do not silently install current or bypass a higher-priority/discovery-only source. Define how an explicit catalog/source selector interacts with precedence and the currently parsed but unused bundle component source field.
• Preserve the behavior of unqualified search, info, add, install, and update commands. Expose available versions and exact selection consistently where appropriate (for example, info <id> --versions and catalog-backed add <id> --version <version>). Keep --from as a direct-URL option, not a catalog selector. A bundle-level --version would select a bundle release; it must not override component pins in bundle.yml.
• Bundle component pins must resolve the requested release from a trusted source. Download the selected release rather than looking up its ID again; validate its URL/redirects and checksum, and verify the downloaded component's ID and version before installation. Online bundle validation must check the exact version, not merely the ID. Report missing historical releases clearly without synthesizing URLs from tags or silently substituting newer versions.
• Define installed-component conflicts: a project currently has one installed version per component ID. Installing two bundles that require different versions of that ID must not silently count the second pin as satisfied by the first.
• Integration catalogs should support versioned metadata lookup, but historical integration install --version is out of scope until historical integration implementations have a supported distribution/install contract. Document that distinction.

Delivery requirement: dedicated PRs per area

Do not implement this as one cross-cutting PR. Deliver separate, reviewable PRs for each catalog family—extensions, presets, workflows, steps, bundles, and integrations—plus a separate bundler PR that consumes exact-version component resolution and handles pin/conflict behavior. If shared contracts or catalog utilities are required, introduce them in a dedicated foundation PR first. Each area PR should carry its own focused tests and documentation; land dependent work in a deliberate sequence so existing single-version behavior stays supported throughout.

Acceptance criteria

• Each catalog family accepts legacy one-version entries and customer-authored multiple-version entries, with tested current and exact lookups and deterministic source precedence.
• The associated CLI preserves current defaults and clearly distinguishes displayed versions from installable versions; discovery-only community entries cannot be installed through exact-version selection.
• Catalog-backed historical installs fail explicitly when the requested version or artifact is unavailable, and verify the selected artifact's identity/integrity.
• Bundles can install their pinned historical component releases from configured install-allowed catalogs and reject incompatible already-installed versions rather than silently skipping them.
• Regression coverage includes old clients' expected current-version fields, missing/malformed releases, source policy and precedence, and version-specific metadata; reference documentation describes the new format and limits.

Related: https://github.com/github/spec-kit/issues/4712.