Muse Code provider for BB

# Muse Code provider for BB

Runs [Muse Code](https://developer.meta.com/ai/products/muse-code/) — Meta's
terminal coding agent, powered by Muse Spark — as a first-class BB provider.
Threads on this provider get the same surfaces as a bundled one: streamed
timeline, tool rows, approvals, model picker, health, installation, and a
subscription usage meter.

## How it works

Muse ships an in-process protocol of its own: `muse serve` hosts sessions over
stdio and speaks the **Muse Session Protocol** (MSP) — a JSON-RPC command plane
(`session/start`, `turn/start`, `approval/decide`) plus a view stream of
notifications (`item/started`, `item/delta`, `turn/completed`,
`session/tokenUsage`). The plugin's bridge translates that stream into BB's
delta grammar, so BB's assembler mints every turn and item id and Muse's own
ids stay join keys.

Each thread gets its own `muse serve` child, so no thread can disturb another's
configuration, sandbox posture, or session state.

## Security posture, stated plainly

**This provider runs with Muse's own OS sandbox off, and with network access
allowed.** Both are defaults, both are settings, and the reasons are in
[Why Muse's OS sandbox defaults to off](#why-muses-os-sandbox-defaults-to-off)
and the section after it. What that means in practice:

- A shell command Muse runs is confined by nothing at the OS level. BB's
  permission modes and its approval flow are the enforcement surface. Under
  `full` — BB's documented approval bypass — that surface is deliberately empty.
- Sandboxed shell commands, if you turn the sandbox on, are allowed network by
  default rather than Muse's `proxy-only`, because `proxy-only` truncates the
  `bb` CLI's larger responses.
- Set **Muse's own OS sandbox** to `on` for OS-level containment. It costs you
  native toolchains: nothing that invokes Swift or Clang builds under it.

BB's injected tools reach Muse over a loopback socket on 127.0.0.1, bound to an
ephemeral port. One bridge process serves every thread, so that socket is a
boundary between them: each thread's MCP server holds a credential minted for
that thread and for the exact tools BB declared for it, and a call is answered
only where the presented secret, the stated thread, and the named tool all
belong to the same grant. Credentials are revoked when the thread is discarded
and replaced when its tool set changes. The tool is checked again