Extensions — register one Animator, Connector and capability profile end to end

[zenithruneblade]

Prove the complete extension-author path for adding one Animator-backed capability and its Connector without hard-coding a provider into Core.

This is a bounded child of #63 and an integration of #21, #42 and #55—not a replacement for their ownership. Canonical boundaries live in ADR 05 — Extensions, ADR 22 — Dispatcher and ADR 23 — Orchestrator.

First working slice

• Choose one exact local Soulstone or remote Portal capability already suitable for Capabilities — admit one typed non-model service #42's bounded service-call contract.
• Register, as separate shaped contributions, its semantic interface revision, immutable profile, Connector dialect-driver revision, Rune schema, Animator/runtime activation definition and evidence binding. Registration of one kind must not synthesize another.
• Bind the concrete Provider separately from interface/profile identity. A familiar protocol or “OpenAI-compatible” label grants no semantic compatibility, model support, readiness or authority.
• Validate all cross-store references as one staged generation, then seal membership. Configuration may select exact registered identities but cannot name Python classes, fabricate profiles or create a live Connector.
• Build and probe the Animator through its owning lifecycle, publish fresh capability observations, obtain an exact Dispatcher grant/lease, invoke through the Connector and release/contain it on success, refusal, timeout and cancellation.
• Cover local/remote custody, secret references, network/effect authority and recovery explicitly. A waiting Graph retains no live Connector, provider SDK object or grant.
• Demonstrate enable → new Vessel generation → call succeeds and disable/upgrade → new generation → old identity is unavailable or explicitly retained for pinned work.

Boundary

An Animator is an addressable service handle, the Connector is its typed conduit, Dispatcher grants exact use, and Orchestrator owns physical readiness. None becomes a second Graph, scheduler, policy engine or application owner.

Open decision

Coordinate with #21/#42 on the exact first service/profile. Reuse their chosen bounded modality when possible rather than creating a second demonstration solely for this issue.

Connections: #5 model runtimes, #6/#16 orchestration, #7/#17 dispatch, #21 registration, #42 general service capability, #55 Portal call, #65 package lifecycle.
Verification: registration/selection fixtures, real bounded probe/call, grant cleanup, cancellation, restart and revision mismatch. Shared contribution rules: #52.