load dialog: reachable address field, project mode, and a way back from a bad answer

Three bugs, reported together, with one shared root: you couldn't get to the
address field, so the address went into the processor filter, so IDA got a
nonsense processor name and refused to open — and the app dead-ended with a
misleading error.

**Tab never reached any modal.** Binding("tab,shift+tab", "toggle_view",
priority=True) is an APP binding, and priority bindings run before the focus
chain. Nothing in any dialog in this app could ever be tabbed to; the load
dialog is just where it finally mattered. action_toggle_view now hands the key
back when a modal is up, which fixes it everywhere.

**...and DOM order was the wrong tab order anyway.** focus_next() stopped at the
processor list, which is arrow-driven and has nothing to type. LoadOptionsScreen
overrides it to cycle the two fields you actually type into.

**...and the dialog outgrew the terminal.** With the palette's default
max-height the 21-row list pushed the address field and help line off the bottom
of the screen. Nothing errors — the field simply isn't there, which reads as
"Tab does nothing". Capped per-dialog.

**Project mode never asked.** _should_ask_load_options bailed on
`self._project is not None` with the comment "project mode carries per-binary
options already" — true only if someone had already filled them in. A raw blob
added to a project got the silent x86-at-0 treatment the dialog exists to
prevent. Now asked at boot AND on switching to an undescribed binary, and the
answer is written back to the project entry (Project.set_load), so it is asked
once per binary, not once per run.

**A rejected answer dead-ended.** Getting a processor wrong is an ordinary
mistake; it left an empty app with "connect failed: worker exited (code 1)" and
a message blaming a locked .i64. The worker now names the real suspect when load
switches were in play, and the app re-opens the dialog instead of giving up.

Verified with real keys in a tmux pane, which is the only way any of this shows
up: Tab -> address field -> 0x8000000 -> Enter -> 35 functions at 0x80039AC; a
bogus processor -> "those load options were rejected — try again" with the
dialog back; project mode -> asks, loads at the right base, and the answer is in
the project file.

tests: +3 scenarios (Tab moves focus under a modal, lands on the address field,
cycles back). 202/0 scenarios, 39/0 project, 32/0 formats, 30/0 project UI.
docs/TEXTUAL_NOTES.md gets the priority-binding and clipped-modal traps.

1 files changed, 23 insertions, 0 deletions

diff --git a/idatui/project.py b/idatui/project.py
index 8f2674d..e2fc542 100644
--- a/idatui/project.py
+++ b/idatui/project.py
@@ -239,6 +239,29 @@ class Project:
     def refs(self) -> tuple[BinaryRef, ...]:
         return self._refs
 
+    def set_load(self, label: str, processor: str = "", base: int = 0,
+                 ida_args: str = "") -> BinaryRef | None:
+        """Record how ``label`` should be loaded, and persist it.
+
+        Answered once: the dialog that asks writes the answer here, so reopening
+        the project doesn't ask again — and neither does adding the same blob to
+        another project, since it travels with the entry.
+        """
+        ref = self.by_label(label)
+        if ref is None:
+            return None
+        i = self._refs.index(ref)
+        e = self._entries[i]
+        if processor:
+            e["processor"] = processor
+        if base:
+            e["base"] = int(base)
+        if ida_args:
+            e["ida_args"] = ida_args
+        self._refs = self._build_refs()
+        self.save()
+        return self._refs[i]
+
     def by_label(self, label: str) -> BinaryRef | None:
         return next((r for r in self._refs if r.label == label), None)