Make self-improvement analyst backend selection explicit

[eloylp]

Context

PR #672 introduces the self-improvement recommendation inbox. The analyzer runs as a synthetic self-improvement-analyst agent created by the workflow at runtime.

Today its backend is selected automatically by selfImprovementBackend():

1. Prefer codex when configured with a command.
2. Else prefer claude when configured with a command.
3. Else use the first configured backend by sorted name.
4. Else fail analysis because no backend is configured.

That is pragmatic for the first implementation, but the behavior is hidden from operators.

Problem

The self-improvement analyst is an important system component, but operators cannot explicitly choose which backend/model it uses.

This can surprise users when:

• codex exists but the operator expected claude for analysis quality.
• A local backend exists and sorts before another backend.
• Different workspaces want different self-improvement backends.
• Operators need to control cost, latency, privacy, or model capability for improvement analysis.

Desired Direction

Make self-improvement backend selection explicit while keeping a safe default for existing installs.

Possible shape:

self_improvement:
  backend: codex
  model: gpt-5.5

or under an existing daemon/runtime config section if that better matches the current schema.

Expected behavior:

• If configured, use the configured backend/model for the synthetic self-improvement-analyst run.
• Validate that the backend exists and has a command.
• Validate pinned model availability consistently with normal agents.
• If unset, preserve the existing fallback order for compatibility: codex, then claude, then first configured backend.
• Surface the selected backend/model in traces/runners as today through the normal run lifecycle.
• Document the selection behavior.

Open Questions

• Should this be global daemon config, workspace config, or both?
• Should the self-improvement analyst eventually become a real editable agent row instead of a synthetic runtime agent?
• Should the backend/model be exposed in the UI near the recommendation inbox or in the config area?
• Should there be a different backend setting for future periodic catalog-auditor runs?

Non-goals

• Do not change recommendation generation semantics.
• Do not auto-apply recommendations.
• Do not require every install to configure this before using self-improvement.
• Do not add the ai ready label until the config shape is decided.