registry: migrate substrate from AgentCore registry to standalone Agent Registry service

[Kalindi-Dev]

Summary

The #246 agent asset registry is currently backed by the AgentCore registry control plane (bedrock-agentcore-control). We're migrating to a new standalone "Agent Registry" service with its own endpoints. This tracks that substrate swap.

Background

The registry integration was deliberately built behind a port/adapter boundary so a substrate swap is confined to the adapter layer. Every consumer (handlers, the orchestrator resolve-step, the agent's read path) talks through the RegistryClient port, never a raw SDK client.

Scope — what changes

New adapter(s) targeting the Agent Registry service endpoints, plus config/wiring:

• cdk/src/handlers/shared/registry/agentcore-client.ts → new Agent Registry adapter (full port: publish / getRecord / listRecords / resolve)
• cdk/src/handlers/shared/registry/factory.ts — build the new client; replace AGENT_REGISTRY_ID / bedrock-agentcore-control wiring with the new service's endpoint/config
• agent/src/registry/agentcore_client.py → new read-side adapter (get_record / resolve) against the new endpoints
• Re-express the record shape (descriptorType CUSTOM/AGENT_SKILLS/MCP, _meta runtime extraction, name decode kind/namespace/name) against the new service's record model
• IAM: replace AgentCore control-plane permissions with the new service's actions (provisioning + orchestrator/session roles)
• cdk/src/handlers/registry-provisioning/index.ts — provisioning against the new service
• New ADR (or update to ADR-022) documenting the migration decision and endpoint model

Out of scope

• The port interfaces themselves (client.ts / client.py) should not need to change — that's the point of the boundary. Flag if the new service's semantics force a port change.

Open questions

• New service endpoint / API shape and auth model?
• Data migration for existing published records, or fresh publish?
• Cutover strategy — dual-write/dual-read, or hard swap?