Investigate packaging the extension and presets as a single spec-kit bundle

[dgarros]

Need

Bootstrapping the OpsMill spec-kit stack in a consumer repo currently means running
six independent install commands, in the right order, from three different sources:

1. specify extension add opsmill (this repo)
2. specify extension add review (ismaelJimenez/spec-kit-review)
3. specify extension add critique (arunt14/spec-kit-critique)
4. specify extension add reconcile (stn1slv/spec-kit-reconcile)
5. specify preset add taskstoissues-jira (this repo)
6. specify preset add --dev …/presets/reconcile-opsmill (this repo, needs a git clone)

Nothing ties those six together. There is no single artifact that says "this is the
OpsMill stack", and no statement of which combination of versions has been validated
together — the extension is at 1.2.0, the presets are versioned independently, and
release history is split across two changelogs. Order matters (reconcile-opsmill is
inert unless the reconcile extension is already installed), but that only lives in
README prose, and a partial or out-of-order install fails quietly: the preset lands,
the command it overrides never appears.

This affects anyone standing up a new repo on the house workflow, and it costs us
maintenance — install instructions are duplicated across the root README and two
preset READMEs, and each new preset adds another step to keep in sync.

Spec-kit's bundle primitive looks like the right shape for this: a curated,
versioned, installable unit composing extensions and presets, installed in one step.
Notably it would cover the presets too, which today are strictly bolted on afterwards.

We should investigate what it would take to ship the OpsMill stack as a bundle, and
confirm it actually delivers the one-step install we want before committing to it.

Context

• What this repo ships today: the opsmill extension (extension.yml, 7 commands,
  1 opt-in hook) plus two presets (presets/taskstoissues-jira,
  presets/reconcile-opsmill), each with its own preset.yml and README.
• Three third-party extensions are hard dependencies of the current surface:
  critique and review (used by prep / auto / implement) and reconcile
  (whose command the reconcile-opsmill preset overrides).
• Licensing is not uniform across the components — the extension and
  taskstoissues-jira are Apache-2.0, reconcile-opsmill is MIT (it carries its own
  LICENSE, being derived from an MIT upstream extension).
• Worth settling as part of the investigation: whether the individual extension and
  preset install paths stay supported alongside a bundle, or the bundle becomes the
  only documented entry point.
• Bundle support is new upstream, so the investigation should start from the current
  state of the reference and the spec-kit release we'd be targeting.

References

• Spec Kit bundles reference: https://github.github.com/spec-kit/reference/bundles.html
• Current install instructions: README.md (§ Install, § Companion extensions),
  presets/taskstoissues-jira/README.md, presets/reconcile-opsmill/README.md
• Manifests: extension.yml, presets/*/preset.yml