loading: a blob that analyses to nothing is still openable

Pick a random .bin, say ARM at 0x4000, and you got two empty panes and
"functions still loading…" — which was a lie; loading had finished. _auto_land
falls back to the symbol picker when there's no entry function, and the picker
answers an empty index with that message. Nothing ever opened.

Zero functions is not a corner case. It's exactly what a real firmware image
looks like when it's described wrongly, and IDA has no complaint of its own to
make about it, so this was the last silent-wrong-answer in the blob path.

Now:

* Land in the listing at the start of the image. The bytes exist even when no
  code was recognised, so there is always something to show.
* Say so, in the status bar, for as long as it stays true — an image with no
  functions is a property of the database, not an event, and writing it once
  meant the next status write erased it (the same clobber that bit the split
  view's "decompiling…").
* Ctrl+L re-asks. The .i64 has the old processor and base baked in and takes
  precedence over any switches, so reloading means deleting it; the confirmation
  says what that costs, and when there are no functions it says nothing is lost.

Verified with real keys on a random 64K blob: ARM @ 0x4000 lands showing
"db 65536 dup(?)" with the hint in the status; Ctrl+L -> confirm -> dialog ->
metapc reloads at 0. The hint survives scrolling.

tests: new tests/test_blob_ui.py (11) driving a real random blob end to end —
lands, has rows, right base, honest status, hint survives navigation, Ctrl+L
offers the reload and declining leaves the binary open. 202/0 scenarios, 30/0
project UI.

(Harness note for future me: tmux send-keys reads "0x4000" as a hex KEY CODE and
sends U+4000. Use send-keys -l for literal text.)

1 files changed, 19 insertions, 0 deletions

diff --git a/docs/PROJECTS.md b/docs/PROJECTS.md
index 88ce2f6..10274ab 100644
--- a/docs/PROJECTS.md
+++ b/docs/PROJECTS.md
@@ -297,6 +297,25 @@ conversion happens in `BinaryRef.load_args`, and a base that isn't 16-byte
 aligned is rejected rather than silently landing somewhere else. `ida_args`
 passes anything else through untouched.
 
+### When analysis finds nothing
+
+Zero functions is what a raw image described wrongly looks like — right file,
+wrong architecture, and IDA has no complaint to make about it. The app used to
+fall through to the symbol picker, which had nothing to show, so you got empty
+panes and a status reading "functions still loading…" long after loading had
+finished.
+
+Now it opens the listing at the start of the image (the bytes are there even when
+no code was recognised) and the status bar carries the diagnosis for as long as
+it's true:
+
+    seg000 @ 0x0  [listing]  — no functions: wrong processor/base? Ctrl+L to reload
+
+`Ctrl+L` re-asks. The database IDA already built has the old processor and base
+baked into it and wins over any switches, so reloading means deleting it — hence
+the confirmation, which tells you what you'd lose (and, in this case, that you'd
+lose nothing).
+
 Two things worth knowing:
 
 * The options apply to the **first** open only. Afterwards the `.i64` records how