Docs: refresh backend catalog consumer status

docs/.internal/extension-host-migration/openclaw-capability-catalog-and-arbitration-spec.md

@@ -618,7 +618,7 @@ Capability selection must emit structured events for:
 - channel capabilities from `extensions/discord/src/channel.ts:74`, `extensions/slack/src/channel.ts:107`, and `extensions/telegram/src/channel.ts:120` collapse into canonical messaging action families
 - diffs becomes an agent-visible tool family plus a host-managed route surface from `extensions/diffs/index.ts:27`
 - provider integration from `extensions/google-gemini-cli-auth/index.ts:24` becomes operator-visible setup and auth capabilities
-- catalog-backed runtime-family descriptors for embeddings, media, and TTS now route through `src/extension-host/runtime-backend-catalog.ts`; TTS request setup and status already consume that catalog order, and broader consumer adoption and arbitration should continue moving those subsystem runtimes toward runtime-internal registries rather than leaving them as a universal plugin-provider API shape
+- catalog-backed runtime-family descriptors for embeddings, media, and TTS now route through `src/extension-host/runtime-backend-catalog.ts`; TTS request setup and status, media auto-selection and default-model lookup, and memory doctor guidance for embedding auto-provider order already consume that catalog data, and broader consumer adoption and arbitration should continue moving those subsystem runtimes toward runtime-internal registries rather than leaving them as a universal plugin-provider API shape
 - extension-backed web search should become an agent-visible tool family unless it is only a runtime-internal backend feeding another host-owned surface
 - voice-call from `extensions/voice-call/index.ts:230` becomes a mix of agent-visible actions, runtime providers, and operator surfaces
 - ACP backend registration from `extensions/acpx/src/service.ts:55` becomes runtime-internal backend arbitration

docs/.internal/extension-host-migration/openclaw-extension-host-implementation-guide.md

@@ -265,6 +265,7 @@ Committed implementation slices so far:
 - `ed5941ed7e` `TTS: extract payload planning`
 - `454e44242f` `TTS: extract API composition`
 - `6240fb31b5` `TTS: adopt runtime backend catalog`
+- `cfb6779ac2` `Runtime: adopt backend catalog consumers`
 - `89414ed857` `Docs: track extension host migration internally`
 - `d8af1eceaf` `Docs: refresh extension host migration status`
 
@@ -284,7 +285,7 @@ Recent plan refinements:
 - it now explicitly treats interactive callback routing, namespace ownership, dedupe, and fallback behavior as first-class migration surfaces
 - it now explicitly treats inbound claim as a canonical ingress-stage concern rather than a permanent plugin-era hook shape
 - it now explicitly treats Telegram and Discord as the first validated rollout targets for interactive control surfaces while keeping the underlying contracts generic, host-owned, and kernel-agnostic
-- it now explicitly treats embeddings, media understanding, and TTS as in-progress host-owned subsystem runtimes, with embedding selection, fallback routing, public runtime surface, result typing, manager-side batch and fallback policy, sync plus reindex planning, sync plus reindex orchestration, reindex sync-body execution plus unsafe reset, safe-reindex temp-db creation, file swap, reopen, and cleanup, plus runtime-backend catalog descriptors now extracted, media registry, execution, auto-entry selection, active-model fallback, orchestration, planning helpers, remaining API composition, lazy entrypoint wiring, plus runtime-backend catalog descriptors now extracted, TTS registry, execution, request setup, config normalization, preferences, payload planning, shared status state, API composition, plus runtime-backend catalog descriptors now extracted, with TTS request setup and status already consuming that catalog order, and broader consumer adoption and arbitration on top of those catalog-backed runtime-family descriptors still pending, all with capability routing, typed request envelopes, provider-id normalization, and fallback policy
+- it now explicitly treats embeddings, media understanding, and TTS as in-progress host-owned subsystem runtimes, with embedding selection, fallback routing, public runtime surface, result typing, manager-side batch and fallback policy, sync plus reindex planning, sync plus reindex orchestration, reindex sync-body execution plus unsafe reset, safe-reindex temp-db creation, file swap, reopen, and cleanup, plus runtime-backend catalog descriptors now extracted and memory doctor guidance already consuming the catalog-backed embedding auto-provider order, media registry, execution, auto-entry selection, active-model fallback, orchestration, planning helpers, remaining API composition, lazy entrypoint wiring, plus runtime-backend catalog descriptors now extracted and media auto-selection plus media default-model lookup already consuming that catalog order, TTS registry, execution, request setup, config normalization, preferences, payload planning, shared status state, API composition, plus runtime-backend catalog descriptors now extracted, with TTS request setup and status already consuming that catalog order, and broader consumer adoption and arbitration on top of those catalog-backed runtime-family descriptors still pending, all with capability routing, typed request envelopes, provider-id normalization, and fallback policy
 - it now explicitly rejects widening the legacy `registerProvider(...)` or `ProviderPlugin` surface into a universal runtime API while retaining capability routing, typed request envelopes, provider-id normalization, and fallback behavior where those are part of the target model
 - it now explicitly treats extension-backed search as either a canonical tool contribution or a host-owned runtime backend depending on whether the search surface is agent-visible
 

docs/.internal/extension-host-migration/openclaw-kernel-extension-host-transition-plan.md

@@ -251,6 +251,7 @@ Committed implementation slices so far:
 - `ed5941ed7e` `TTS: extract payload planning`
 - `454e44242f` `TTS: extract API composition`
 - `6240fb31b5` `TTS: adopt runtime backend catalog`
+- `cfb6779ac2` `Runtime: adopt backend catalog consumers`
 - `89414ed857` `Docs: track extension host migration internally`
 - `d8af1eceaf` `Docs: refresh extension host migration status`