docs: correct bounds_override lifecycle in README

bounds_override actually survives panel.close(id) + re-open
(drag/resize position persists). It is only cleared by unregister
or _test_reset_all. Previously the README claimed close(id)
cleared it, contradicting the implementation in M.close.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

README.md

@@ -653,15 +653,21 @@ calling `resolve_bounds(opts.layout, sw, sh)`. All render + dispatch +
 `point_in_any_panel` callsites use `get_bounds_for`, so the override
 is consistent across the API.
 
-`bounds_override` survives until:
-- The widget is closed via `panel.close(id)` (cleared).
-- The widget is unregistered.
-- `panel._test_reset_all()` is called.
+`bounds_override` survives:
+- Mouse-release after drag/resize (the moved/resized state stays).
+- `panel.close(id)` followed by `panel.open(id)` — the window re-opens
+  at its last-dragged/resized position. (Spec contract: drag/resize
+  wins over layout-fn.)
 
-There is no public API to clear `bounds_override` — re-opening a closed
-draggable widget gives it the layout-fn's bounds again. Persistent
-windows that drag during a session keep their dragged position until
-the next process start (no save/load yet — deferred post-v0.4.0).
+`bounds_override` is cleared when:
+- The widget is `panel.unregister(id)` (window record destroyed).
+- `panel._test_reset_all()` is called (test backdoor).
+
+Modders cannot programmatically clear `bounds_override` without
+unregister/re-register. A future version may add a
+`panel.reset_bounds(id)` helper if demand emerges. Persistent windows
+that drag during a session keep their dragged position until the next
+process start (no save/load yet — deferred post-v0.4.0).
 
 ### Test backdoors (v0.4.0 additions)