fix(local-ai): avoid stale OpenAI primary after provider hot reload

Summary

Immediately after Local AI setup hot-reloads agents.defaults.model.primary and models.providers.llamacpp, the embedded agent can still dispatch one or more requests through the stale openai/gpt-5.6-sol primary. On a Local AI-only installation with no OpenAI credential, the first prompt fails with missing-provider-auth even though the llama.cpp provider configuration was just applied.

This is separate from #1282. That PR removes stale setup-managed gateway records; it does not synchronize gateway provider reload with embedded-agent dispatch.

Environment

• Windows 11 ARM64 on RTX Spark hardware
• Windows integration branch integration/local-ai-2026-09-02, head 38a172f1
• Gateway OpenClaw 2026.6.34 (5c38f99) in the managed OpenClawGateway WSL distro
• Managed Local AI model: Qwen3.8 27B through the llamacpp provider

Reproduction

1. Run managed Local AI setup from a clean/isolated Windows app state.
2. Complete model/provider configuration.
3. Send the first embedded-agent prompt immediately after setup reports completion and the gateway reports the provider/model hot reload as applied.

Actual behavior

The gateway log shows the new Local AI configuration applied, followed about one second later by a request using the stale OpenAI primary:

2026-09-02T16:59:32.323Z config change detected (agents.defaults.model.primary, models.providers.llamacpp)
2026-09-02T16:59:33.144Z config hot reload applied (agents.defaults.model.primary, models.providers.llamacpp)
2026-09-02T16:59:34.174Z ProviderAuthError: No API key found for provider "openai"
2026-09-02T16:59:34.186Z requestedProvider="openai" requestedModel="gpt-5.6-sol" code="missing-provider-auth"

After the provider/model configuration is applied again and the gateway settles, the same installation routes correctly:

2026-09-02T17:03:55.625Z provider=llamacpp model=qwen3.8-27b-mtp-ud-q4-k-m POST /v1/chat/completions
2026-09-02T17:04:36.148Z provider=llamacpp status=200

The user-visible failure is:

Agent failed before reply: No API key found for provider "openai" ... | missing-provider-auth

No OpenAI provider is intended or required for this Local AI-only setup.

Expected behavior

Once the grouped provider/model reload reports success, every newly dispatched embedded-agent request should resolve the new llamacpp primary. A request must not observe stale model/provider state or tell the user to configure an unrelated OpenAI credential.

Suggested acceptance criteria

• Apply the provider registration and default-model switch atomically from the embedded agent's point of view.
• Gate or retry first dispatch while provider/model state is reloading instead of falling through to stale auth state.
• Add a deterministic test that pauses reload between config persistence, provider registration, agent model resolution, and first dispatch.
• Add current-head proof for setup completion followed immediately by a successful first Local AI prompt without a manual gateway restart or second config write.

Diagnostics

• The setup log setup-engine-20260902-164018.jsonl records a separate pre-cleanup recipe-mismatch failure and is not the source of this provider-auth error.
• The relevant evidence is in gateway logs around 2026-09-02T16:59:32Z through 17:04:36Z.
• Identifiers and tokens are intentionally omitted from the excerpts above.

No source files or existing tests are named. Start with the gateway hot-reload sequence in the logs, then trace provider registration, agent model resolution, and the embedded-agent first dispatch; done means a deterministic reload test and a setup-completion run that sends the first Local AI prompt successfully without a restart or second config write.