feat(gui): give both Meta providers their brand mark

devlog/_plan/260903_muse_release_train/000_plan.md

@@ -0,0 +1,77 @@
+# 260903 — Muse release train: regression review, provider mark, v2.41.0
+
+## Why this unit exists
+
+`origin/dev` is 36 commits ahead of `origin/main`, which still carries
+`v2.40.0` (published 2026-09-02). Three of those commits are the Meta/Muse
+line that landed today:
+
+- `878f75417` (#3317) — Muse Spark 1.3 registered on the 1.2 spec.
+- `ff1ac6b8c` (#3321) — the direct Meta Model API provider (`meta-model`).
+- `1aa839aa8` (#3337) — the `meta-muse` provider importing the Muse Code CLI
+  credential behind a Terms-of-Service warning.
+
+The user asked for three things, in order: regression-review the 36-commit
+delta against `main`, give Muse a provider mark in the dashboard, and run the
+release through to a published Meta/Muse-carrying version.
+
+## Constraints that shape every phase
+
+- **No local full suite.** `bun run test` and a bare `bun test` are forbidden
+  for this unit. Verification is focused `bun test <file>`, `bun run typecheck`,
+  and exact-SHA GitHub CI (`ci.yml` + `service-lifecycle.yml`).
+- That constraint is load-bearing on the release path. `scripts/release.ts`
+  runs the whole suite in its preflight, so the helper cannot be used here.
+  The release therefore takes the manual path the helper would otherwise
+  automate: bump on the release branch, wait for both exact-SHA workflows,
+  then `gh workflow run release.yml` with `version`/`tag`/`expected-sha`.
+- `--no-verify` pushes are authorized; PRs target `dev` and merge with admin
+  once CI is green.
+- `main` and `preview` carry rulesets requiring a pull request. Promotion is
+  by PR, not by push.
+
+## Work phases
+
+| Phase | Doc | Deliverable |
+|-------|-----|-------------|
+| wp0 | this unit | roadmap + review method (docs only) |
+| wp1 | `010_wp1_regression_review.md` | per-commit regression record for all 36 commits |
+| wp2 | `020_wp2_muse_mark.md` | Meta/Muse SVG + `provider-icons.ts` wiring |
+| wp3 | `030_wp3_preview_release.md` | `preview` dist-tag publish, exact-SHA proof |
+| wp4 | `040_wp4_main_release.md` | `latest` dist-tag publish, ancestry proof |
+
+wp1 and wp2 are independent of each other and both gate wp3. wp4 consumes
+wp3's published preview.
+
+## Review method (wp1)
+
+A 36-commit delta is too large to re-derive from scratch, and re-reading every
+diff line would produce a document nobody checks. The review is risk-classed
+instead, and the class decides what evidence is required:
+
+- **R0 docs-only** — `devlog/` or `docs-site/` only. Evidence: the diff touches
+  no runtime path. No test needed.
+- **R1 scoped runtime** — one subsystem, covered by a focused test file that
+  already exists. Evidence: the focused test passes at the dev head.
+- **R2 cross-cutting** — touches routing, the model catalog, release
+  automation, or a shared contract. Evidence: focused tests plus a read of the
+  seam the change crosses.
+- **R3 credential/security** — auth, tokens, OAuth, keychain, workflow
+  permissions. Evidence: line-level read of the credential path plus
+  `privacy:scan`.
+
+The Muse commits are R2 (#3317, #3321) and R3 (#3337).
+
+Three more are R3, corrected after audit round 1 (`005`): `7ce0ba518` (#3262)
+grants `contents: write` and `pull-requests: write` to a reusable-workflow
+call, `7a529a2e8` (#3318) changes `pull_request_target` processing — a declared
+trust boundary in `.github/AGENTS.md` — and `3c7c021ec` (#3296) touches
+provider credential admission. A workflow-permission grant is a credential
+change even when the diff reads like plumbing, which is the hole the first
+draft of this table had.
+
+## What "done" means here
+
+`main` carries the reviewed dev SHA, npm `latest` resolves to the stable
+version built from it, and `ocx` users installing fresh get Muse Spark 1.3
+plus both Meta providers with a real mark in the dashboard.

devlog/_plan/260903_muse_release_train/005_audit_round1_synthesis.md

@@ -0,0 +1,84 @@
+# Audit round 1 — synthesis
+
+Reviewer: delegated read-only auditor (gpt-5.6-sol, high). Verdict: **FAIL**,
+seven findings. Every one was re-derived against the tree before folding; the
+outcome is six folded and one rebutted-with-a-carve-out.
+
+## 1. "ToS enforcement is bypassable" — REBUTTED as a release blocker, RECORDED as a known limit
+
+The reviewer is right about the mechanism and wrong about what it means for
+this release.
+
+The mechanism, confirmed: `loginMetaMuse` emits its warning through the
+optional `ctrl.n` progress callback (`src/oauth/meta-muse.ts:128`). The CLI's
+own OAuth path wires that to `console.log` (`src/oauth/login-cli.ts:87`), so
+`ocx login meta-muse` prints it. The management API's flow, by contrast,
+installs `n: () => {}` (`src/oauth/index.ts:1720`) and drops it on the floor —
+which means `POST /api/oauth/login` and `ocx account login meta-muse`, which
+goes through that same endpoint, never surface the warning text. The GUI shows
+`OAuthTosWarningModal` client-side, so the acknowledgement is enforced by the
+browser, not by the server.
+
+Why it does not block:
+
+- **It is not a regression and not Muse-specific.** `n: () => {}` predates this
+  work by a long way, and `anthropic` and `google-antigravity` — the other two
+  `HIGH_RISK` ids in `gui/src/oauth-tos-risk.ts:10` — have carried exactly the
+  same client-side-only gate since `fbac9f05e`. Shipping v2.41.0 changes the
+  exposure for none of them.
+- **The credential path itself is clean.** The reviewer looked for a leak and
+  found none: no Keychain stderr surfaced, no response bodies in errors, a fixed
+  public error vocabulary, atomic 0600 persistence.
+- **The bypass requires the user's own admin token.** `/api/oauth/login` is
+  behind management auth. The actor who can call it is the account holder, who
+  is the only party the ToS warning protects, and who has already installed and
+  signed into the Muse Code CLI on that machine.
+
+What it is: a real server-side consent gap across all three high-risk
+providers, worth its own unit. It is recorded here and in
+`050_followups.md` rather than folded into a release cycle, because a
+backend consent boundary is a behaviour change for `anthropic` and
+`google-antigravity` users too, and that does not belong in a release train
+the user asked to ship today.
+
+## 2-5. Release-path corrections — FOLDED
+
+All four are correct and all four are now in the phase docs:
+
+- **Version availability before the bump.** `scripts/release.ts:513` checks
+  unused-version and channel-forward ordering BEFORE mutating anything; the
+  workflow's own duplicate check at `release.yml:303` runs only after dispatch.
+  Doing this by hand means proving the version unused first, not discovering it
+  from a failed publish. Live state at audit time: `latest=2.40.0`,
+  `preview=2.40.0-preview.20260902`, `2.41.0` unused.
+- **Exact-SHA is stricter than "CI passed".** `release-dispatch-guard.cjs:14`
+  requires a lowercase 40-char SHA, an allowed ref, a `workflow_dispatch`
+  event, and equality with `GITHUB_SHA`; `release.yml:222` requires a
+  successful **push-event** CI run on the release branch — PR CI does not
+  satisfy it.
+- **`dev` already carries `2.41.0`.** `package.json:3`. The main bump in the
+  original 040 was a no-op step; promotion carries the version with it. The
+  post-release workflow is `dev-version-bump.yml`, and its PR moves `dev` to
+  `2.42.0`.
+- **Publishing is OIDC Trusted Publishing.** `release.yml:119` (`id-token:
+  write`), `:153` (npm >= 11.5.1), `:285`. No `NPM_TOKEN`; verify provenance
+  and `gitHead` after publish.
+
+## 6. Risk classification — FOLDED
+
+`7ce0ba518` (#3262) grants `contents: write` + `pull-requests: write`
+(`release.yml:67`) and `7a529a2e8` (#3318) changes `pull_request_target`
+processing, a declared trust boundary (`.github/AGENTS.md:16`). Both move R2 ->
+R3. `3c7c021ec` (#3296) touches provider credential admission and also gets R3.
+
+## 7. Icon wiring — FOLDED
+
+The set is `MASKED_PROVIDER_ICONS` (`gui/src/provider-icons.ts:188`), not
+`MASKED_MARKS`; `020` named the client-side set by mistake. `meta.svg` carries
+three gradients, so the masking question does not arise — the mark is colour and
+is drawn as an image. Provenance goes in the asset README, and the two ids get
+explicit assertions rather than relying on the generic wiring check.
+
+Reviewer's own non-blocking note, confirmed: no test enumerates every registry
+provider's display name, and `tests/provider-workspace-data.test.ts` does not
+need changing.

devlog/_plan/260903_muse_release_train/010_wp1_regression_review.md

@@ -0,0 +1,56 @@
+# wp1 — Regression review of the 36 dev-ahead-of-main commits
+
+## Input
+
+`git log --oneline origin/main..origin/dev` at the head recorded in
+`000_plan.md`. Baseline is `v2.40.0`.
+
+## Method
+
+Each commit gets one row: SHA, PR, risk class (R0-R3 per `000_plan.md`), the
+evidence actually checked, and a verdict of `clean`, `accepted`, or `blocker`.
+A `blocker` must be fixed on `dev` before wp3 starts; an `accepted` row must
+say why the residual risk is tolerable in a release.
+
+Evidence is gathered without the full suite:
+
+- `git show --stat <sha>` for the touch set of every commit.
+- For R1/R2, the focused test file that owns the subsystem, run individually.
+- For R3, a line-level read of the credential handling plus
+  `bun run privacy:scan`.
+- `bun run typecheck` once at the dev head covers the type-level seams that a
+  per-commit read would otherwise have to reason about by hand.
+
+## Special attention: the Meta/Muse line
+
+Three questions decide whether this release is safe to publish:
+
+1. **Does `meta-muse` ever write the imported credential anywhere a log or a
+   scan can see it?** #3337's follow-up (`81c1ebe8c` on the feature branch,
+   squashed into `1aa839aa8`) redacts scanned secrets and bounds the Keychain
+   read. Verify the redaction covers the error paths, not just the happy path.
+2. **Can the ToS warning be bypassed?** The provider is deliberately marked
+   unsupported; the warning is the only thing standing between a user and an
+   unauthorized use of their Muse Code subscription.
+
+   The verdict rule, so a later reader reaches the same decision this unit
+   did. A bypass is `UNSAFE` and blocks the release when it is EITHER of:
+
+   - a **new** bypass introduced by a commit in this delta, or
+   - any path that **discloses the credential** (a log line, an error body, a
+     serialized config field).
+
+   A bypass is **accepted** only when all three hold: it predates the delta,
+   it applies identically to the other `HIGH_RISK` providers rather than
+   singling out `meta-muse`, and it is recorded in `050_followups.md` with
+   the file:line evidence. That is exactly one case here — the client-side-only
+   acknowledgement on `POST /api/oauth/login` — and `005` §1 is why it
+   qualifies. Anything that does not meet all three is `UNSAFE`.
+3. **Does Muse Spark 1.3 leak into a provider that cannot serve it?** #3317
+   added 1.3 on the 1.2 spec across the resellers; the registry must not
+   advertise 1.3 on a provider whose upstream roster lacks it.
+
+## Output
+
+`011_review_ledger.md` — the per-commit table. Written in wp1's B phase, not
+here.