reasoning_effort from settings.json is silently replaced by `high` when the value is outside EFFORT_LEVELS

[yoke-yoke]

Thanks for the adapter, it has been running well for us through kandev.

Summary

When ~/.config/muse/settings.json carries a reasoning_effort value that is not in
EFFORT_LEVELS, defaultSessionConfig replaces it with high and nothing is logged.
The session then runs at high while both the settings file and the model's own
picker suggest otherwise.

This is easy to hit, because the muse CLI advertises a wider vocabulary than the
adapter accepts:

$ muse exec --help
--reasoning-effort <EFFORT>
    Meta reasoning effort: none|minimal|low|medium|high|xhigh|max|ultra

max is documented there but absent from EFFORT_LEVELS (src/config-options.ts:13),
so a user who writes the value their own CLI documents silently gets high.

Reproduction

1. ~/.config/muse/settings.json contains { "schema_version": 1, "reasoning_effort": "max" }
2. Start a session through any ACP client.
3. The session runs at high. No log line, no warning, nowhere.

Checked directly against the published 0.6.1 dist:

import { defaultSessionConfig } from "./dist/config-options.js";
for (const v of ["max", "ultra", "xhigh"])
  console.log(v, "->", defaultSessionConfig({ model: "muse-spark-1.3", reasoningEffort: v }).reasoningEffort);
// max   -> high
// ultra -> ultra
// xhigh -> xhigh

Why this reads as a bug rather than a deliberate choice

The same file already treats the same invalid input loudly when it arrives from a
client (src/config-options.ts:135):

if (!isReasoningEffort(value)) {
  throw RequestError.invalidParams(undefined, `unknown reasoning effort: ${value}`);
}

And readMuseSettings already reports its two other failure modes, a missing file
and a non-object document (src/muse-settings.ts:31 and :35). Only an out-of-range
value goes unreported.

Suggestion

Report it where the logger already lives, in readMuseSettings:

if (typeof settings.reasoning_effort === "string" && !isReasoningEffort(settings.reasoning_effort)) {
  logger.log(`muse settings at ${path}: unknown reasoning_effort "${settings.reasoning_effort}"; using the default`);
}

Keeping the fallback is fine, only the silence is a problem. It cost us a few hours
of looking in the wrong place, because the level Muse displayed and the level in
effect disagreed with each other.

Secondary observation, lower value

EFFORT_LEVELS gates both backends, but muse-exec.js forwards the value straight
to --reasoning-effort, where the CLI does accept max. So under
MUSE_CODE_ACP_BACKEND=exec, a value the target supports is filtered out before it
reaches it. I have not exercised that path, so treat this as an observation rather
than a report.

Environment

@bex-co/muse-code-acp 0.6.1, Muse Code 1.3.0, Linux aarch64, model muse-spark-1.3.