[Bug]: Muse provider: muse-ember-1.0 fails in T3 when contributor mode is on (no contributor deployment exists)

[sittingmongoose]

Summary

With Muse Code contributor mode enabled (contributor_mode_enabled: true in ~/.config/muse/settings.json), any T3 thread or delegated task on model muse-ember-1.0 fails immediately:

model `muse-ember-1.0` does not exist or you lack access

The same model works when run directly with the Muse CLI on the same machine, same account, same muse binary.

Versions

• T3 Code: 0.1.8-nightly.20261109.4433 (Linux, Ubuntu VM)
• Muse Code: 1.4.14 (1.4.14-R7309.1), provider instance muse (binaryPath = local muse)
• Muse provider: Meta (https://api.meta.ai/v1), OAuth device-code login, subscription active

Root cause (traced locally)

1. With contributor mode on, the muse serve host that T3 launches resolves the selected model to its contributor deployment at request time. For muse-wonder-full-1.0 that is muse-wonder-full-1.0-contributor, which exists, so Wonder threads work in T3.

2. Meta's model catalog for this account (~/.local/share/muse/model-catalog/*.json, source provider_catalog) lists contributor variants for Wonder and Spark models but no muse-ember-1.0-contributor row:

   muse-ember-1.0, muse-spark-1.2, muse-spark-1.2-contributor,
   muse-spark-1.3, muse-spark-1.3-contributor, muse-wonder-1.0,
   muse-wonder-1.0-contributor, muse-wonder-full-1.0,
   muse-wonder-full-1.0-contributor
   

3. The failed session log (~/.local/share/muse/sessions/.../session.jsonl) records the upstream attempt verbatim: operation model.response, system meta, http_status: 404, requested model muse-ember-1.0-contributor. The 404 is surfaced to the user as "does not exist or you lack access", naming the base model, which sends debugging in the wrong direction (account/quota).

4. The direct CLI paths (muse exec --model muse-ember-1.0, TUI) resolve to the base muse-ember-1.0 deployment and succeed with the same settings file. So the model, account, and credentials are fine; only the serve path's contributor resolution lacks a fallback when no contributor variant exists.

This blocks using Ember in T3 entirely (threads and delegate_task children) while contributor mode is on, with no per-model opt-out: muse exposes contributor mode only as one global setting plus a per-process --contributor-mode on|off serve flag.

Repro

1. Enable contributor mode in muse settings.
2. In T3, start a thread (or delegate a task) on provider muse, model muse-ember-1.0, any prompt.
3. Turn fails in ~1s with the error above. Control: muse exec --model muse-ember-1.0 "Reply with the word: ok" succeeds on the same host.

Asks

• Surface the actually-requested deployment and HTTP status in the thread error (the current message names a model that was never requested).
• Consider a per-model or per-instance contributor override for the Muse provider (e.g. launch muse serve --contributor-mode off), so one model without a contributor deployment does not require disabling contributor mode globally.
• The underlying resolution bug (serve requests a nonexistent contributor deployment instead of falling back to the base model like exec does) is muse-side; forwarding that evidence upstream would help. Filing here first because T3 is where the failure is visible and where a workaround lever can live.