[Feature]: Add community bundle submissions

[SiCar10mw]

Problem Statement

Bundles are a first-class Spec Kit surface in the CLI and docs, but the repository currently has community submission paths only for extensions and presets. There is no bundle submission issue template, community bundle publishing guidance, or documented maintainer review path for adding role/team stacks to a community bundle catalog.

This leaves bundle authors with an awkward path: they can host a bundle catalog independently and tell users to add it manually, but there is no standard community lane similar to extension_submission.yml or preset_submission.yml.

There is also an important installability detail to settle before accepting community bundle entries: a bundle composes primitive components, and those component references still need to resolve through the user's installed/bundled components or active extension/preset/workflow catalogs. A bundle catalog entry alone is not enough if the referenced components are only available in a separate third-party catalog.

Proposed Solution

Add a community bundle submission lane that mirrors the existing extension and preset paths:

• Add a Bundle Submission issue template for authors to provide bundle metadata, release artifact URL, dependency/component summary, validation evidence, and proposed catalog entry.
• Add community bundle publishing guidance that explains what maintainers check and what users should review before installing.
• Document that bundle entries must either reference components available from built-in/active catalogs or clearly list any companion catalog URLs needed for installation.
• Decide, before accepting installable community bundle entries, whether bundle installation should support component-level source metadata or catalog dependency metadata so a bundle can resolve its companion extension/preset catalogs without manual setup.

Alternatives Considered

• Keep bundles as fully self-hosted third-party catalogs only. This works technically, but it makes bundles less discoverable than extensions and presets.
• Ask authors to submit every primitive component separately and avoid bundle submissions. This loses the main bundle value: a versioned, one-command stack for a role, team, or domain.
• Add a bundle catalog entry without dependency-resolution guidance. That risks entries that show up in search but fail to install for users who do not already have the companion catalogs configured.

Use Cases

• A security/compliance team publishes a role bundle that installs its governance presets and verification extension together.
• A product team publishes a product-manager bundle that composes a preset, workflows, and steps.
• Organizations want discoverable examples of complete Spec Kit stacks without copying several catalog add and install commands.

Acceptance Criteria

• A bundle submission issue template exists.
• Community bundle publishing guidance documents required metadata, release artifact expectations, validation commands, and trust boundaries.
• The docs explain the dependency-resolution requirement for bundle components.
• The implementation path for community bundle discovery/install policy is either documented or tracked separately before maintainers accept installable community bundle entries.

Additional Context

SicarioSpec v0.5.1 has a live bundle artifact and companion preset/extension catalogs, which exposed the dependency-resolution question above. The bundle installs correctly when all three catalogs are registered, but a standalone bundle catalog entry would not be enough for a clean user install unless the referenced components are also resolvable.