nbrowser_close_window never replied (30s timeout on every call, window closed anyway) since 0.5.1; fixed in 0.16.3
Found 2026-09-03 while verifying #41 on AdomLapper: every nbrowser_close_window returned status:timeout after 30s through ab, and 70s straight at the bridge's own HTTP port, while the window had in fact closed and the extension had emitted window_closed. verbDurations still showed 14 samples averaging 80 ms, which is why the battery's close row never went red: a completed reply is what records a sample, and none had completed for a while.
Cause, in bridge/server.js: the reply post-processing shared one branch for nbrowser_close_window and nbrowser_cleanup and did (payload.closed || []).map(...). cleanup replies closed:[{windowId}]; close_window replies closed:true. true.map threw, the throw was swallowed inside the async frame handler, and the reply was never sent. The shipped 0.5.1 zip carries the same line, so the PUBLIC tier has this defect today.
Fix (0.16.3, insiders): Array.isArray guard on closed, and the whole reply decoration (file spill, badge and taskbar bookkeeping, activity row, auto-flash) moved into decorateReply() called inside try/catch, so a decoration bug can never eat a reply again; a failure lands as _postError on the reply instead. Verified on AdomLapper after landing 0.16.3: open then close returned status ok in 144 ms with closed:true, an activity row for nbrowser_close_window (origin relay), and no window left behind.
Public desktops get this with the next promote of the public manifest. Closing as fixed on the insiders tier.