Advisor mode falls back when explicitly configured to the primary model

Start in extensions/advisor.ts and trace ensureRuntime() through resolveModelAndThinking(), focusing on how explicit advisor configuration is distinguished from an absent mode. Reproduce the case with an advisor provider and model matching the primary session, then verify that /advisor uses the configured model while an absent configuration still falls back to the built-in default.

Summary

/advisor cannot be configured to use the same model as the primary Pi session. If modes.json explicitly sets advisor to the current primary model, the extension treats that as if no advisor model was configured and falls back to the built-in default.

Reproduction

1. Start Pi with primary model openai-codex/gpt-5.5.
2. Configure ~/.pi/agent/modes.json or project .pi/modes.json:

{
  "modes": {
    "advisor": {
      "provider": "openai-codex",
      "modelId": "gpt-5.5",
      "thinkingLevel": "xhigh"
    }
  }
}

3. Run /advisor on or /advisor status.

Actual behavior

The advisor does not use openai-codex/gpt-5.5. It falls back to the built-in default advisor model.

Expected behavior

If modes.json explicitly configures an advisor model, /advisor should use that model even when it is the same model as the primary session.

Suspected cause

In extensions/advisor.ts, ensureRuntime() calls resolveModelAndThinking(), then uses object identity against the current primary model as a sentinel for “mode absent”:

const sameAsPrimary = resolved.model === ctx.model;
model = sameAsPrimary ? undefined : resolved.model;

But resolveModelAndThinking() also returns ctx.model when the configured advisor mode intentionally resolves to the same provider/model as the primary session. That makes an explicit config indistinguishable from a missing config.

Minimal fix idea

Check whether the advisor mode exists separately from whether the resolved model equals ctx.model, or make resolveModelAndThinking() return whether a mode spec was found/applied.