The menu case was wrong in a way the motion-path patch only hid.
MENU OWNERSHIP CHANGES WITH NO POINTER MOTION. `MenuPrompt` opens and
closes the menu, and re-deriving the icon only on motion meant opening
while an I-beam showed left it on screen over the menu, and closing left
the arrow over text --- in both cases until the pointer happened to
move. The icon is a function of the state, so it is now re-derived where
the state changes.
That makes the motion-path call REDUNDANT, and it is removed rather than
kept: motion inside an open menu changes no ownership, and a second
writer there is one no row could distinguish from the first. This is the
option review offered, and it is the better half --- the transition is
where the fact lives.
The new row drives `apply_attach_message` --- the production path ---
and asserts `last_cursor_icon`, the value actually written, across both
transitions with the pointer never moving. Dropping the `MenuPrompt`
call fires it. The decision-half row stays separate so a failure says
whether the DECISION or the APPLICATION broke; dropping the
`menu.is_some()` guard fires both.
And the blank-area row documented a mutation that was not the one run.
`hit_test_source_byte` takes `&mut self` and the helper is `&self`, so
the literal substitution does not compile; the executed mutation bounds
`x` by the glyphs' extent, which is the same semantics geometrically.
The row now records what was executed and why the literal one is
unavailable.
Levi Neuwirth
e8bc6750ae