feat(delegate): label sessions and show estimated token savings - #150

`lfm2_paged_budget_forced_warm_continue_parity` reddened `main` on three
consecutive runs (#148, #149, #150) with one signature: the warm paged continue
and the flat carried-state oracle agreed for 23 bytes and then split at the
first content word after `<think>` ("keep" vs "what"), `first_diff_byte=Some(23)`
identical on every run, while the same commit passes on a developer host.

The failing run's own log rules out the carry path and the fixture: `turn1` and
`FLAT turn1` are both `"</think> Ok"`, and `cached_tokens` (23) and `num_tokens`
(32) match on both sides. What split is the first *free-form* decision inside the
thinking span — exactly the kind of near-tie the accepted ~1-ULP paged-vs-flat
kernel-stack class flips (`models/lfm2/attention.rs`, plus this file's own
"deliberately NOT asserted" note for long generations). Byte parity was being
asserted over a coin flip.

Fix: run turn 2 budget-forced like turn 1, so both arms commit the same forced
`</think>` first and the compared tokens are answer-region ones. Byte parity
stays fatal; nothing is weakened.

Also asserted now, because they were missing: the arms' turn-1 outputs are equal
(turn 1 is cold, so a mismatch is a fixture lottery and the message says so
instead of sending a reader into the continue path), the reuse lengths are equal,
and the committed token counts are equal (the qwen3 sibling already asserts that
one).

Verified: gate passes locally with both arms byte-identical (`[PASS] … warm
cached=23, tokens=32`); the count invariant was confirmed to fire by temporarily
shortening the flat oracle's turn 2 — "the arms committed different token counts
(warm=32 flat=31)".

…ns (#152)

## The problem, corrected

`main` failed `e2e lfm2` on three consecutive runs (#148, #149, #150),
and it is **not** a random flake — it is host-dependent determinism:

```
[warm-cont] turn1:             num_tokens=2 finish=length raw_text="</think> Ok"
[warm-cont] FLAT turn1:        num_tokens=2 finish=length raw_text="</think> Ok"     ← arms identical before the boundary
[warm-cont] turn2 WARM:        num_tokens=32 cached_tokens=23 finish=length
[warm-cont] turn2 FLAT oracle: num_tokens=32 cached_tokens=23 finish=length          ← same reuse, same length
WARM raw_text="<think> Okay, let's see. The user said to keep going from where I left off, but …"
FLAT raw_text="<think> Okay, let's see what the user is asking here. They said, \"Now …"
```

`first_diff_byte=Some(23)` is identical on all three red runs, and the
same commit passes locally. So the carry path is fine, the arms are
comparable, and what split is the first **free-form** decision inside
the thinking span — the near-tie that this file already documents as
flippable by the accepted ~1-ULP paged-vs-flat kernel-stack class
(`models/lfm2/attention.rs`, and the *"Deliberately NOT asserted:
byte-equality of the answer texts"* note on the memory-probe test). Byte
parity was being asserted over a coin flip.

I first tried downgrading that assertion to a diagnostic; an adversarial
review rightly rejected it — *"a stale or incorrect conv tensor can
preserve turn-1 output, reuse 23 tokens, and generate 32 incorrect
tokens"*, so invariants cannot replace the bite. This is the reviewer's
own recommended alternative instead.

## The change (one file)

- **Turn 2 is now budget-forced, like turn 1.** Both arms therefore
commit the same forced `</think>` first and the compared tokens are
answer-region ones, not a sentence-opening word choice. The boundary
under test (turn-1/turn-2 carry, `ContinuedLivePrefix`, 23-token prefix)
is untouched.
- **Byte parity stays fatal** — the assertion is unchanged in strength.
- **Three invariants added**, which the fixture was missing: the arms'
turn-1 outputs must be equal (turn 1 is cold, so a mismatch is a fixture
lottery, and the message says so instead of sending a reader into the
continue path), the reuse lengths must be equal, and the committed token
counts must be equal (the qwen3 sibling already asserts that one).

## Verification

| Check | Result |
| --- | --- |
| Targeted test locally | `[PASS] … (warm cached=23, tokens=32)`, both
arms byte-identical |
| Whole gate file locally | 9 passed, 0 failed |
| New count invariant actually fires | confirmed by temporarily
shortening the flat oracle's turn 2 → `the arms committed different
token counts (warm=32 flat=31)` |
| `cargo fmt --all` | touched only this file |
| **On the affected (CI) host** | CI dispatched on this branch: [run
34939712245](https://github.com/mlx-node/mlx-node/actions/runs/34939712245)
— result will be posted here |

## What is still not proven

The compared region is now answer-region, but a near-tie there is still
possible in principle, so this is a **fixture pin validated on the
affected host**, not a proof that the split was harmless rounding. The
durable instrument is the one `models/qwen3/model.rs` uses for its
mixed-step gate: logits at turn-2's first forward within
`test_support::bf16_scaled_tolerance`, plus `top - second > 2 ×
tolerance`. That needs a logits readout a test can reach — `ChatResult`
carries none and `Lfm2Inner` is crate-private — so it is a follow-up,
not something to fake with a looser text comparison here.

This clears the `model-test` gate that has been skipping `Publish` on
`main`.

…igning (#153)

## What failed

The v0.0.14 desktop release ([run
34937845040](https://github.com/mlx-node/mlx-node/actions/runs/34937845040))
failed in `Sign, notarize, publish` → `Verify bundle
(pre-notarization)`:

```
[2/5] every Mach-O carries a Team ID
  scanned  18 Mach-O files
[3/5] no build paths baked into load commands
  FAIL     leaks a build path: Contents/Resources/app/node_modules/tokenizers/tokenizers.darwin-arm64.node
           /Users/runner/work/tokenizers/tokenizers/bindings/node/target/aarch64-apple-darwin/release/deps/libnode.dylib
BUNDLE GATE: FAIL
```

## Why, and why it is our fixup to make

That path is the binary's **`LC_ID_DYLIB`** — its own install name,
written by the publisher's CI:

```
LC_ID_DYLIB  /Users/runner/work/tokenizers/tokenizers/bindings/node/target/aarch64-apple-darwin/release/deps/libnode.dylib
LC_LOAD_DYLIB /usr/lib/libc++.1.dylib
LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib
LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib
```

`tokenizers` arrived with the delegate token counter (#150) and is
loaded lazily by `packages/dashboard/src/ingest/tokenizer.ts`. This is
the same defect `mlx-core` and `@napi-rs/keyring` ship with, and
`package.ts` already rewrites both with `install_name_tool -id
@rpath/<file>` on the staged copy, before packager/codesign. Rewriting
the install name is therefore the established remedy here — not
excluding the package (the token counter is a live feature) and not
carving it out of the gate (the gate is what caught this).

`stage-app.ts` already ships exactly one slice of the package — its copy
filter keeps only `tokenizers.darwin-arm64.node` — so a single rewrite
covers the bundle.

## The change (one file)

```ts
// The dashboard's delegate token counter imports `tokenizers` lazily, and
// stage-app ships exactly one slice of it. Its upstream LC_ID_DYLIB carries the
// publisher's CI path …, which is the same defect mlx-core and keyring arrive
// with, and step [3/5] of verify-bundle refuses it. Rewrite the staged copy.
const tokenizersBinary = 'tokenizers.darwin-arm64.node';
run('install_name_tool', ['-id', `@rpath/${tokenizersBinary}`, join(STAGE_APP, 'node_modules', 'tokenizers', tokenizersBinary)]);
```

## Verification

| Check | Result |
| --- | --- |
| Step [3/5]'s own logic on the real binary, before the rewrite |
`["/Users/runner/work/tokenizers/tokenizers/bindings/node/target/aarch64-apple-darwin/release/deps/libnode.dylib"]`
|
| Same check after the rewrite | `[]` |
| `process.dlopen` of the rewritten copy | loads |
| `yarn typecheck` | clean |
| `verify-bundle.test.ts` + `stage-app.test.ts` | 64/64 |

I discarded an earlier attempt that carved third-party prebuilds out of
step [3/5]; the real defect turned out to be fixable in the bundle,
which keeps the gate absolute.

## Re-releasing needs your call

The workflow checks out `inputs.dry_run ? github.ref :
refs/tags/<release_tag>`, so:

- **Validate this fix** — dispatch with `dry_run: true` on `main` (or
this branch): it builds and signs, and step [3/5] should pass.
- **Publish v0.0.14** — not possible from the current tag: `v0.0.14`'s
tree does not contain this fix. Either move the tag onto the fixed
commit, or cut `0.0.15` from `main`.

My recommendation is `0.0.15`: the number `0.0.14` already exists (npm
may hold it), and re-pointing a tag after a publish makes one version
mean two different trees.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Packaging-only Mach-O install-name rewrite on the staged app tree;
mirrors existing mlx-core/keyring fixups with no auth or data-path
changes.
> 
> **Overview**
> Fixes desktop release **verify-bundle** step **[3/5]** failing on
`tokenizers.darwin-arm64.node`, which ships with the publisher’s CI path
in **`LC_ID_DYLIB`** (same issue already handled for **mlx-core** and
**keyring**).
> 
> **`package.ts`** now runs **`install_name_tool -id
@rpath/tokenizers.darwin-arm64.node`** on the staged copy under
`node_modules/tokenizers` before packager/codesign, so the delegate
token counter’s lazy **`tokenizers`** import can stay in the bundle
without weakening the gate.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
6b24c95. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->