feat(meta-muse): accept a pasted Muse Code key on Windows and Linux

devlog/_plan/260904_cross_platform_parity/000_problem_model.md

@@ -28,8 +28,9 @@ claim is mostly FALSE and the exceptions are concentrated:
 So this unit is not a porting sweep. After four audit rounds it is three phases,
 each its own PR in a stacked chain:
 
-- **wp1** - `meta-muse` refuses on Windows and Linux with accurate reasons
-  instead of a false macOS-Keychain one.
+- **wp1** - `meta-muse` accepts a pasted Muse Code key on Windows and Linux. The
+  key is visible in Meta's own console, so refusing those platforms reported a
+  limitation of our importer as a limitation of the platform.
 - **wp2** - a platform-support reference page, so the capabilities that stay
   macOS-only have a written answer rather than a silent dead end.
 - **wp3** - the Windows identity decode fix, the one defect proven to exist in

devlog/_plan/260904_cross_platform_parity/002_muse_cli_storage_measurement.md

@@ -68,11 +68,8 @@ the secret is file-backed, the field naming the file.
 
 ## What wp1 must therefore deliver
 
-- Windows: replace the misleading macOS-Keychain refusal with an accurate one
-  that names WSL2 and the supported `META_MODEL_API_KEY` alternative. No WSL2
-  pointer read: reachability was never measured, and a refusal that tells the
-  truth is a fix while a guess is not.
-- Linux: a refusal naming the unmeasured storage rather than the Keychain. No
-  reader until a real pointer is measured.
+- Windows and Linux: a manual paste field, because the same key is visible in
+  Meta's developer console. No reader on either platform until a real pointer is
+  measured, and no WSL2 bridge: reachability was never measured either.
 - Neither platform may weaken the ToS consent warning, which is the CLI's only
   warning surface.

devlog/_plan/260904_cross_platform_parity/010_wp1_muse_manual_key.md

@@ -0,0 +1,96 @@
+# 010 - wp1: meta-muse manual key entry off macOS
+
+One PR. Base `dev`. Branch `codex/260904-muse-platform-refusals`.
+Evidence: `002`. Revised after audit round 1 and implementation review rounds 1-3.
+
+## Scope change, and why
+
+The first two drafts of this phase shipped REFUSALS: Windows and Linux would fail
+with an accurate message instead of the old inaccurate one blaming the macOS
+Keychain. Audit round 1 had already cut a Linux credential READER, because the
+pointer interface declares no path or inline-key field and writing against
+invented schema is what `meta-muse.ts` refuses to do everywhere else.
+
+Then the repository owner pointed out the thing both drafts missed: **the Muse
+Code API key is visible in Meta's own developer console.** A user on Windows is
+not out of options, they are out of an IMPORT path. Refusing the whole platform
+because our importer cannot read its store, while the vendor hands the same key
+to the user in a browser, reports a limitation of the importer as a limitation of
+the platform.
+
+So this phase now ADDS a capability rather than only correcting prose.
+
+## The change
+
+### `src/oauth/meta-muse.ts`
+
+**Manual entry off darwin.** `loginMetaMuse` calls `manualKeyCredential`, which
+fires `ctrl.onAuth` so the GUI renders its paste field, then awaits
+`ctrl.onManualCodeInput`. This is the shape `kiro.ts:405` already uses when no
+local token exists; resolving the flow first is load-bearing, because otherwise
+the await blocks and the dashboard never receives a response.
+
+**Two reasons, not one.** Windows and Linux are unavailable for different
+reasons, and the instructions say which: Meta ships no native Windows build,
+while the Linux CLI exists and only its credential storage is unmeasured.
+Implementation review round 3 caught the collapsed version telling a Linux user
+something false about their own machine.
+
+**One validator for both origins.** `validatedMetaMuseCredential` does the
+`LLM|` grammar check and the live `GET` against the Model API for imported and
+pasted keys alike. A pasted key that skipped either would be a weaker credential
+wearing the same provider id, and the difference would surface only as a 401
+mid-session.
+
+The macOS error strings are preserved VERBATIM. Extraction is a refactor, and a
+refactor that quietly rewrites a user-facing error is a behavior change in
+disguise (review round 3, blocker 3).
+
+**A host with no paste surface still refuses**, naming `dev.meta.ai` and
+`META_MODEL_API_KEY`. An empty paste refuses rather than storing a blank
+credential.
+
+**`refreshMetaMuseToken` preserves the origin.** `merged()`
+(`src/oauth/index.ts:754`) keeps any source that is not `local-cli`, so returning
+`local-cli` unconditionally would relabel a hand-pasted key as an imported one on
+its first refresh. It now takes the existing credential and preserves `manual`.
+
+### `src/providers/registry.ts` and `docs-site`
+
+The note, the decision record, and the providers guide all described the provider
+as import-only and macOS-only. All three now describe macOS import plus
+Windows/Linux paste, and the consent warning says "the key you import or paste".
+
+## What is deliberately NOT here
+
+A Linux credential reader. `002` records that no Linux pointer has ever been
+observed, and `050` records the four facts one would have to supply. Manual entry
+makes that reader a convenience rather than a blocker, which is a better place
+for it to sit.
+
+A WSL2 bridge. Reaching into `\\wsl$\<distro>\...` needs distro enumeration and
+a reachability probe, neither measured.
+
+## Tests - `tests/meta-muse-oauth.test.ts`
+
+1. Windows offers a paste field naming `dev.meta.ai`; the credential returns
+   `source: "manual"` with `access === refresh`.
+2. Linux offers the same field.
+3. A pasted key still faces the grammar check, and a 401 still fails the login.
+4. A host with no paste surface refuses with an actionable message.
+5. An empty paste refuses rather than storing a blank credential.
+6. The consent warning precedes every unsupported-platform path.
+7. Refresh preserves `manual` and still reports `local-cli` for an imported key.
+8. **No failure path echoes the credential**, across four cases: imported and
+   pasted, each with a rejected (401) and an unreachable (socket) upstream,
+   asserting absence from the error, the stack, `onProgress`, AND `onAuth`. The
+   old single-case version only ever exercised the macOS path, so its name
+   overclaimed once a second route existed (review round 3, blocker 4).
+
+## Acceptance
+
+- `bun test tests/meta-muse-oauth.test.ts` green.
+- `bun x tsc --noEmit` clean.
+- macOS import path byte-identical in behavior, including error wording.
+- No credential value reaches a log, an error, or a callback payload.
+- CI green.

devlog/_plan/260904_cross_platform_parity/050_followups.md

@@ -70,7 +70,7 @@ already scoped it.
 
 ## WSL2 credential bridge for meta-muse
 
-`010` refuses on Windows with an accurate message instead of reading a WSL2
+`010` offers manual key entry on Windows instead of reading a WSL2
 pointer at `\\\\wsl$\\<distro>\\home\\<user>\\.config\\muse\\auth.json`. Doing that
 properly needs distro enumeration, Linux-user mapping, and a reachability probe,
 none of which were measured. A guess would ship an unverified credential path,

docs-site/src/content/docs/guides/providers.md

@@ -458,16 +458,21 @@ material off it. Muse Spark is also reachable through resellers, with a narrower
 `command-code` carries both tiers, while `opencode-go` serves only
 `muse-spark-1.3-contributor`.
 
-**Meta Muse Code (`meta-muse`).** If you already use the Muse Code CLI, this imports the
-API key it stored after `muse login` instead of asking you to provision a second one.
-macOS only — the CLI keeps that key in the macOS Keychain, and no other platform's
-storage has been verified. OpenCodex never launches the CLI: if no credential is present
-it tells you to run `muse login` yourself.
+**Meta Muse Code (`meta-muse`).** On macOS, if you already use the Muse Code CLI, this
+imports the API key it stored after `muse login` instead of asking you to provision a
+second one. OpenCodex never launches the CLI: if no credential is present it tells you to
+run `muse login` yourself.
+
+Elsewhere it asks you to paste the key. Meta ships no native Windows CLI, and on Linux the
+CLI exists but where it stores its credential has not been verified, so OpenCodex refuses
+to guess at a credential store and points you at [dev.meta.ai](https://dev.meta.ai)
+instead, where the same key is visible. A pasted key faces the same format check and the
+same live validation against the Model API as an imported one.
 
 **Read this before enabling it.** Meta scopes that credential to the Muse Code CLI, so
 using it here is an *unsupported* path. Meta does not authorize subscription coverage
 outside its own client, how these calls settle is not observable from the API, and you
-should treat every call as billable against your account. The imported key is copied into
+should treat every call as billable against your account. The key, imported or pasted, is copied into
 OpenCodex's auth store (`~/.opencodex/auth.json`, mode 0600) like every other OAuth
 credential. The dashboard shows a Terms-of-Service warning before the first login and
 before any reauthentication — the same treatment Anthropic and Google Antigravity get.