EFFORT_LEVELS is missing `max` because @muse-code/sdk is pinned to 0.1.1

[yoke-yoke]

Follow-up to #11, and the reason behind it.

Summary

EFFORT_LEVELS is missing max because the adapter pins @muse-code/sdk to 0.1.1,
and that version's protocol type does not have it yet. The SDK caught up one day after
0.6.1 was published:

@bex-co/muse-code-acp 0.6.1   published 2026-09-17   pins "@muse-code/sdk": "0.1.1"
@muse-code/sdk       1.3.0    published 2026-09-18

// @muse-code/sdk 0.1.1, dist/src/msp.d.ts:819
type ReasoningEffort = "none" | "minimal" | "low" | "medium" | "high" | "xhigh" | "ultra";

// @muse-code/sdk 1.3.0, dist/src/msp.d.ts:950
type ReasoningEffort = "none" | "minimal" | "low" | "medium" | "high" | "xhigh" | "max" | "ultra";

So max is not a CLI-only vocabulary as I assumed in #11. It is in the wire protocol,
between xhigh and ultra, matching the order the CLI documents:

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

The gap is client side only

Adding "max" to EFFORT_LEVELS in the installed 0.6.1, changing nothing else and
leaving the SDK at 0.1.1, is enough for a real turn to run at max over ACP:

effort advertised by the session : "max"
offered values : none,minimal,low,medium,high,xhigh,max,ultra
turn completed, stopReason = end_turn

No error, no downgrade, no complaint from the host. The value is forwarded as a string
(turn-submit.js only copies it), so the stale type never blocks it at runtime. It is
the adapter's own isReasoningEffort gate that rejects it, in both defaultSessionConfig
and sdkReasoningEffort.

For contrast, a level the account is not entitled to fails loudly and helpfully, which is
how I know the silence on max was a vocabulary gap and not an entitlement one:

$ muse exec --reasoning-effort ultra ...
tbh: reasoning effort ultra is not available (gate ultra_reasoning_effort is closed); using xhigh

Suggestion

Bump @muse-code/sdk to 1.3.0 and add "max" to EFFORT_LEVELS. I did not send a PR for
this one: the jump from 0.1.1 to 1.3.0 crosses a major version and may touch more of the
adapter than the effort list, so the shape of the change is yours to decide. Happy to do
the work if you would rather delegate it, including the narrow variant that only adds the
value without moving the dependency.

Either way #11 stays relevant: whatever the accepted list becomes, a value outside it is
currently replaced by high with nothing logged, which is what sent me looking in the
wrong place for half a day.

Environment

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