Automate curation of the acq configure opt-in kit list (metadata should live with the kits in -patterns) #508

Summary

The acq configure opt-in kit picker (added in
#500) is populated from a hard-coded catalog
in acq.backends/common.sh — a parallel-array literal of kit names +
one-line descriptions (ACQ_OPTIN_KIT_NAMES / ACQ_OPTIN_KIT_DESCS), resolved
against the pinned PATTERNS_KIT_REF. For a new kit in the
agentic-coding-patterns
repo (integrations/isolation/acq-kits/) to show up in the picker today, a
maintainer must manually (1) bump PATTERNS_KIT_REF and (2) hand-edit the two
arrays in lockstep. That is easy to forget and drifts from the source of truth.

We should automate curation of the list.

Proposal

Move the picker's per-kit metadata into the patterns repo, alongside the kits
themselves (the natural source of truth), and have acq read + filter it
instead of carrying its own copy:

• Each kit's one-line summary (the short description shown in the picker)
  should live with the kit in -patterns — e.g. a summary: field in
  integrations/isolation/acq-kits/kits.yaml (which today only carries long
  parity: prose), or equivalent per-kit metadata.
• Each kit's status (e.g. functional vs. skeleton/experimental) should also
  live with the kit, so acq can filter the list rather than relying on a
  human to remember to omit non-functional kits. (Concretely: prime-agent is a
  skeleton at the current pin and is deliberately left out of the hard-coded
  catalog today — exactly the kind of thing a machine-readable status should
  drive.)
• acq then derives the opt-in picker list from that pinned metadata (built-ins
  stay mandatory), so bumping the pin is the only step to surface new kits — no
  hand-edited catalog to drift.

This keeps the pinned/reproducible model intact (the metadata is read at the
pinned PATTERNS_KIT_REF, not main); it just removes the duplicated,
hand-maintained catalog in the quickstart.

Notes / dependencies

• This is a cross-repo change: it needs the summary: + status: (or
  equivalent) fields added to the kits in -patterns first, then acq updated
  to read/filter them.
• Implementation options (generator-at-release vs. runtime read, description
  source, enforcement) were discussed but intentionally not decided here —
  this issue only captures the need and the direction (metadata lives with the
  kits; acq reads/filters it).

Relationship

Follow-up to #500 (which introduced the
hard-coded catalog and ADR-0028).