[reliability] DM beats silently drop / hang >10min with no recovery — sabotages story personas (crit)

[100yenadmin]

sweep_v8 narrative+newbie crit. The DM writing is 8+/Disco-Elysium quality, but: beat 1 silently dropped (zero output); beat 3 hung >10min with no recovery path; the session clock raced. This drags narrative 8->6 and is the HIGHEST-LEVERAGE lift (story craft is the product's strength). Likely the DM-latency/streaming + provider-error class (see worldos-latency-forensics): a dropped/timed-out beat needs a provider_error sentinel + a recovery affordance, not silent failure. Part of #591. Wave 1 priority.

[100yenadmin]

Forensics (worldos-latency-forensics, measure-first on the v8 narrative run)

The 'silent drop' + '10-min hang' are NOT real DM unreliability. Measured the 4 dm.*.jsonl result events:

beat	duration_api_ms	ttft_ms	num_turns	in chat?
1	157s	4.7s	16	yes
2	85s	2.4s	6	yes
3	86s	2.9s	4	yes
4	104s	1.9s	3	yes

All four beats ran cleanly (generation-bound ~85-157s = the known latency baseline), model first-token at ttft 2-5s, all recorded in chat with coherent prose, and ZERO timeouts / retries / empty-fallbacks / provider_errors. No dropped beat, no 10-min hang at the DM level.

Root cause: viewer.log streaming refs = 0 — mid-turn narration is not reaching the viewer in this run. The model emits at ttft ~2-5s, but the viewer showed BLANK for the full 85-157s of each beat → the persona perceived a 'drop' (the 157s beat-1) / 'hang' (cumulative). The QA player-agent's own between-turn deliberation further inflates the perceived wait (a real human wouldn't incur it — the skill's documented caveat).

Corrected scope: this is the #571 mid-turn-streaming lever (NEUTRAL, no quality cost), NOT a 'fix dropped/hung beats' task (they aren't dropping).

KEY caveat — may be a HEADLESS-PROXY artifact: streaming could work in the real dist/WorldOS.app while the VM playwright path doesn't replicate it. MUST verify on the BUILT .app (the gate surface): if the .app streams a beat's narration as it composes, this perception does not occur there. Next step: fresh .app build → observe streaming during one beat → if absent, wire/restore streaming in the harnessed viewer path; if present, this is a proxy-measurement artifact (downgrade severity).

Re-scoped from severity:critical 'reliability' → perceived-latency/streaming + verify-on-.app.