fix(rtmg/web): re-dispatch restored LoRA strengths to the engine on session ready

[qianghan]

Summary

Fixes the tracker bug "Web app bug: LoRAs not loading upon refresh / session reload."

Repro (from the tracker): set a LoRA strength to 1, save the session, reload it. The fader still shows 1, but the audio doesn't sound like the LoRA is applied — it only "kicks in" once you wiggle the fader (drop to 0.8, raise back to 1).

Root cause

LoRA strength has two representations in the web client:

• useLoraStore.strengths[id] — the source of truth the fader UI renders.
• usePerformanceStore.sliderValues["lora_str_<id>"] — the engine-facing value that useParamSync actually ships to the pipeline every 8 ms tick.

useParamSync prefers sliderValues and only falls back to lora.strengths when the lora_str_<id> key is absent:

for (const id of lora.enabled) {
  const k = `lora_str_${id}`;
  if (k in raw) continue;           // sliderValues already has it → never read lora.strengths
  const v = lora.strengths[id];
  if (typeof v === "number") raw[k] = v;
}

The boot-time catalog seed (useLoraStore.setCatalog → seedLoraSliderValue) writes a sliderValues entry for the default-on LoRAs. A saved-session resume then restores the persisted strength into lora.strengths only — it never updates sliderValues. So at resume the key is present-but-stale: useParamSync keeps streaming the old seeded value and never reads the restored one. The slider shows 1.0 (reads lora.strengths) while the engine stays pinned to the stale strength.

A fader drag is the first thing that writes sliderValues (via the dispatcher's debounced commit), which is exactly why the LoRA only becomes audible after the user moves the fader. Symptom = "shows 1.0 but inaudible"; true cause = the restored strength is never pushed into the engine-facing sliderValues.

This is a state-restoration / initial-sync gap, not a number-persistence gap — the number persists fine.

Fix

• Add reconcileEnabledLoraStrengths() (engine/lora/dispatcher.ts): for every enabled LoRA, seed perf.sliderValues["lora_str_<id>"] from lora.strengths[id].
• Call it once per session-ready edge in useStartSession — the initial connect path and the reconnect onSuccess path — right after the LoRA cap is finalized.

Why this is regression-safe

• No double-apply on a fresh session: on a non-restored session sliderValues and lora.strengths already agree (both seeded from the same config/defaults), so every write lands the same value. The server only refits on a > 0.02 delta, so re-seeding the matching value triggers no extra refit.
• Never fires before the engine is connected: it runs only on the ready path, with a live remote.
• No per-tick spam: runs once per ready edge, not in the param loop.
• Never mid-drag: ready edges can't overlap a pointer gesture; the dispatcher remains the sole owner of sliderValues during a fader drag.
• Contract-first preserved: no knob/protocol registry was touched (no knobs.py / protocol.py change), so no gen_wire_types.py regeneration is required and the drift guards are unaffected.

Test plan

New focused unit test tests/unit/loraStrengthReconcile.test.ts:

• restoring a session with LoRA strength = 1 over a stale seeded sliderValues results in the engine receiving 1.0 on ready (mirrors useParamSync's exact selection logic);
• a fresh session where the values already agree is a no-op;
• only enabled LoRAs are reconciled.

Evidence:

# typecheck
$ npm run typecheck      → tsc --noEmit, exit 0

# new + lifecycle tests
$ npx vitest run tests/unit/loraStrengthReconcile.test.ts tests/unit/sessionStore.test.ts
  Test Files  2 passed (2)
       Tests  11 passed (11)

# production build
$ npm run build          → ✓ Compiled successfully, exit 0

Note: tests/unit/float16.test.ts and tests/unit/sliceEpoch.test.ts fail locally with TypeError: Math.f16round is not a function — a pre-existing Node-version limitation in the float16 wire helpers, unrelated to this change (no LoRA/param code involved).

Made with Cursor

[seanhanca]

Superseded by #280, re-opened from a branch on this repo (daydreamlive/DEMON) instead of the qianghan fork. Closing this fork-based PR in favor of #280.