loading: a blob that analyses to nothing is still openableHEADmain

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.)

0 files changed, 0 insertions, 0 deletions