feat(registry): central agent asset registry for capabilities, skills, plugins, and MCP servers

### Component

CDK / infrastructure, API or orchestration, Agent (Python runtime), Scripts / CLI

### Describe the feature

Introduce a **central agent asset registry** — a versioned, platform-managed catalog from which agents and blueprints resolve runtime artifacts instead of vendoring them in source or redeploying CDK for every tool/skill change.

The registry holds **typed records** for multiple artifact kinds, including (non-exhaustive):

| Asset kind | Examples |
|------------|----------|
| **Capabilities** | Verification strategies, knowledge-tool configs, task workflow definitions |
| **Skills** | Agent skill packages (prompt + tool guidance) |
| **Plugins** | Claude Code / agent plugin bundles |
| **MCP servers** | Server definitions, tool descriptors, connection config |
| **Prompt fragments** | Reusable system-prompt sections |
| **Cedar policy modules** | Soft-deny packs, repo-specific policy extensions |
| **Event rule packs** | Lifecycle governance rules (pairs with #230) |
| **Notification profiles** | Channel rendering templates |

Each record is **immutable at a given version**; blueprints **pin** semver constraints (no floating `latest` in production). At task start the orchestrator resolves pins, fetches artifacts, and provisions the agent environment — decoupling asset authoring from infrastructure deployment.

This enables **more flexible, capability-driven tasks** beyond the three hardcoded task types (`new_task`, `pr_iteration`, `pr_review`) without forking core orchestrator logic for every new workflow.

### Use case

- **Generic / composable tasks:** Submit work defined by a capability bundle (tools + prompts + validation + policy) rather than a fixed enum task type.
- **Org-wide rollout:** Publish a new MCP server or skill version; blueprints re-pin when ready — running tasks keep their original pin.
- **Reproducibility:** Every execution records which asset versions were resolved (audit + eval).
- **Extensibility without forking:** Teams add skills/plugins/MCP defs through the registry instead of patching `agent/` or CDK per tenant.
- **Governance integration:** Registry becomes the source of truth for tool-surface validation (#230 Change Manifest L1/L5 concepts).

### Proposed solution

**Phase 0 — Schema and API contract**
- Define asset record schema: `{ id, kind, version, semver, descriptor, artifact_ref, publisher, created_at, status }`.
- **Capability descriptors:** structured metadata per asset — tool surface, permissions required, egress domains, Cedar actions introduced, runtime dependencies, minimum compute profile.
- Operator/publisher API: publish, get, list by kind/namespace, resolve (semver constraint → pinned version).

**Phase 1 — Registry MVP**
- Storage implementation (metadata index + artifact blobs) — **implementation choice left to design PR**; this issue does not prescribe specific cloud services.
- Resolve pinned assets at task start; pass resolved bundle to agent hydration / runtime bootstrap.
- CLI: `bgagent registry list`, `bgagent registry show @` (names TBD).

**Phase 2 — Blueprint integration**
- Extend Blueprint construct: `mcp_servers`, `skills`, `capabilities`, policy modules, etc. reference registry IDs + version constraints instead of inline definitions.
- Orchestrator resolves and records resolved versions on the task record.

**Phase 3 — Lifecycle (follow-up or stretch)**
- Deprecate / retire flow; bulk re-pin migration API.
- Cedar-governed publish ACLs (who can publish/pin by asset type and namespace).

**Explicitly out of scope for MVP**
- Full meta-agent tool generation (#99 ToolBuilderAgent vision).
- Replacing shipped repo-local config (`.mcp.json`, `AGENTS.md`) — registry complements per-repo overrides.
- EventBridge as primary bus.

### Acceptance criteria

- [ ] Asset kinds enumerated in schema; at minimum: capability, skill, plugin, mcp_server, cedar_policy_module, prompt_fragment.
- [ ] Publish + resolve API with semver pinning; immutability enforced per version.
- [ ] Blueprint can reference at least one asset kind via registry ID + constraint; orchestrator resolves at task start and persists resolved versions on task metadata.
- [ ] Agent runtime receives resolved artifact bundle and can load an MCP server or skill from registry (one end-to-end path sufficient for MVP).
- [ ] Capability descriptor validated at publish time (required fields, egress/policy declarations).
- [ ] Tests: resolution logic, semver edge cases, pin immutability; docs in design + roadmap sync.

### Other information

- **Roadmap:** Agent asset registry section (`docs/guides/ROADMAP.md`) — Central asset registry, Capability descriptors, Blueprint registry references, Asset versioning, Registry access control.
- **Related:** #230 (event-rule-pack assets defer to registry Phase 3), #99 (broader AKW/generic-task vision — this issue is the focused, current-architecture registry track).
- **Does not replace:** Tool capability tiers (extended tool profile per repo) — may be a separate issue; registry supplies *what* to load, tiers supply *policy gate* on tool surface.

### Acknowledgements

- [x] I may be able to implement this feature
- [ ] This might be a breaking change