IOCP/kqueue: panic on `c.result.?` when a completion is reused while still queued (cursor-blink timer)

[nanasess]

この fork が持つ修正パッチの追跡用 issue(発見可能性を保つため）。修正は #1。

症状

レンダラスレッドで散発的にパニック: Zig の attempt to use null value(STATUS_BREAKPOINT 0x80000003 → abort)。Windows/IOCP で Ghostty のカーソル点滅タイマー使用中、数十分〜数時間で発生。

根本原因

iocp.zig:271 が completion queue のエントリを c.result.? でアンラップしている(「Completion queue items MUST have a result set」)。この不変条件が completion 再利用レースで破られる: タイマーの再武装/reset が loop.timer（c.* = .{...}）を経由して result を null に戻すが、同じ completion がまだ completion queue に連結されたままのため、後続の completions.pop() が null result をアンラップしてパニックする。

同じ c.result.? パターンは kqueue.zig:440 にも存在するため、macOS も構造上は同様に脆弱（未検証）。

修正（#1）

IOCP と kqueue 両方の completion ループで、pop したエントリの result が null の場合は stale エントリとして扱い、（再利用済みの）状態を書き換える前に読み飛ばす。再武装済みの completion は自身のタイミングで発火する。

• IOCP: 実機検証済み（Debug ビルド + 複数日 soak で再発なし。先行していたスクロール停止の前兆も消失）。
• kqueue: パリティ目的のみで未検証（消費側 ghostinthewsl は Windows 専用でこの経路を通らない）。

スコープ / upstream との関係

• この fork は ghostinthewsl が pin する正確な commit（34fa508）+ この 1 パッチを持つ。意図的に upstream main より「behind」(pin 版 + 最小差分）。
• Windows IOCP support は upstream で WIP。[bug] v.next is not proper cleared for re-enqueue a completion between different queues mitchellh/libxev#169 / queue: clear next before re-enqueue mitchellh/libxev#170 は同じ大分類（completion の re-enqueue）を扱うが、queue: clear next before re-enqueue mitchellh/libxev#170 は next をクリアするだけで iocp.zig を触らないため、本ケースは upstream では未対応。

リンク

• 修正: backend: skip stale completion-queue entries with a null result (IOCP + kqueue) #1
• 消費側: Renderer thread panics (null unwrap) in the cursor-blink timer via libxev IOCP backend ghostinthewsl#4（issue）、build(deps): point libxev at the nanasess fork to fix the cursor-blink crash (#4) ghostinthewsl#5（build.zig.zon override）

開示: 診断・修正は AI 支援で行い、実機で検証した。作者は Zig に深く精通しているわけではない。