Fixed switching edit mode while a prompt was running sometimes landing on the wrong mode

[oleg68]

Summary

• While a prompt was running, switching the edit mode (e.g. to Auto Mode) could cycle through several modes and settle on the wrong one, because a single screen-poll read of the footer line could be corrupted by Claude's Ink renderer mid-redraw.
• Applied the same confirm-twice debounce already used for choice-menu detection (cbb745b, f4f4660) to edit-mode detection: a newly detected mode is only applied (continuous sync) or treated as a confirmed transition (explicit Shift+Tab switch loop) once the same mode is seen on two consecutive polls.

Test plan

• Added unit tests reproducing the glitch (single differing poll must not flip the mode) for both the continuous pollScreenState() sync and waitForConcreteModeChange()
• Added unit tests confirming the same mode on two consecutive polls is applied
• mvn test passes
• mvn package succeeds
• Manually verified: switched edit mode while a prompt was running across several repetitions; mode now consistently settles on the one selected

🤖 Generated with Claude Code