Fix: esc in the custom-prompt editor cancelled the whole jump

[navbytes]

Summary

• ⏎ on an earlier tree row opens Pi's 3-choice picker (from Port Pi's fork-from-an-earlier-message flow whole #2); picking "Summarize with a custom prompt" opens a text-entry dialog, and esc there is documented to loop back to the 3 choices, not cancel the whole jump.
• Manual smoke-testing for the v0.2.3 release found this was actually fully cancelling the jump instead — reproduced twice independently with pty screenshots.
• Root cause: the host's dialog stack runs its own post-esc dismissal right after our onCancel handler returns, targeting whatever was on top when esc fired. Our handler was replacing the dialog synchronously inside that same handler, so the host's cleanup wiped the freshly-opened choices dialog straight back off, silently stranding the askJump promise (looks identical to a full cancel — nothing renders).
• Fix: defer the reopen by one macrotask so it runs after the host finishes its own cleanup.

Test plan

• bun run typecheck clean
• bun test — 252 pass, 0 fail
• New e2e regression test added (test/e2e/tui.test.ts): drives esc-in-custom-prompt via pty and asserts it lands back on the picker, not a dangling/cancelled state — confirmed to fail against the old code and pass against the fix
• bun run build clean