loading: say how to read a headerless blob (processor, base)

A raw firmware dump has no format to detect, so IDA fell back to x86 at address
0. It doesn't fail — it opens, analyses, and finds nothing. An AArch64 image
loaded this way gave 0 functions; told the truth it gives 35.

    ida-tui fw.bin --processor arm --base 0x8000000

and per binary in a project, which is what a multi-image firmware actually
needs:

    {"path": "app.bin", "processor": "arm", "base": "0x8000000"}

idapro.open_database() already accepted IDA command-line switches; nothing was
passing any. Plumbed BinaryRef -> WorkerPool -> WorkerClient -> worker argv, plus
a load_args for the single-binary path that has no project ref.

base is written the way people say it (0x8000000, int or string, any base).
IDA's -b is in PARAGRAPHS — -b1000 loads at 0x10000 — so BinaryRef.load_args
converts, and a base that isn't 16-byte aligned is refused rather than silently
landing 16x off. ida_args passes anything else through.

Two bugs found by testing the whole path rather than the happy one:

* Project.load() whitelisted path/label when normalising entries, so the load
  options were dropped the first time a project was reopened — set a processor,
  come back tomorrow, it's gone.
* Re-passing the switches to an EXISTING database makes IDA refuse the open
  (rc != 0, no functions). The .i64 already records how the image was loaded, so
  the worker skips them once a database exists. My first guard checked
  splitext(path) + ".i64" and never fired, because IDA names it "<file>.i64" —
  keeping the extension. It checks both spellings now.

Verified on a real AArch64 blob: fresh load 35 functions based at 0x8002440,
reopen 35 again, and the CLI rejects an unaligned or non-numeric --base.

tests: +6 project (options recorded, paragraph conversion, file round-trip,
add() takes them, an ELF passes nothing, hex-string base). 39/0 project, 195/0
scenarios, 30/0 project UI, 36/0 index, 27/0 pool.

1 files changed, 31 insertions, 0 deletions

diff --git a/docs/PROJECTS.md b/docs/PROJECTS.md
index f4acc91..fdd15a1 100644
--- a/docs/PROJECTS.md
+++ b/docs/PROJECTS.md
@@ -239,6 +239,37 @@ Still open: project-level persistence (remember the active binary and each
 binary's position across sessions — today a fresh launch auto-lands).
 
 
+## Headerless blobs
+
+An ELF/PE/Mach-O says what it is, so IDA figures it out. A raw firmware dump
+says nothing, and IDA falls back to **x86 at address 0** — which on an ARM image
+analyses to zero functions. It doesn't fail; it just quietly gives you nothing.
+
+    ida-tui fw.bin --processor arm --base 0x8000000
+
+or per binary in a project, which is where it belongs for a multi-image firmware:
+
+    {"binaries": [
+       {"path": "bootloader.bin", "processor": "arm",  "base": "0x0"},
+       {"path": "app.bin",        "processor": "arm",  "base": "0x8000000"},
+       {"path": "dsp.bin",        "processor": "mipsb", "base": "0x10000000"}
+    ]}
+
+`base` is written the way you'd say it (`0x8000000`, any base, int or string).
+IDA's own `-b` switch is in **paragraphs** — `-b1000` loads at 0x10000 — so the
+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.
+
+Two things worth knowing:
+
+* The options apply to the **first** open only. Afterwards the `.i64` records how
+  the image was loaded, and passing the switches again makes IDA refuse to open
+  it — so the worker skips them once a database exists.
+* Changing the processor or base of a binary you've already analysed does
+  nothing, because the database wins. Delete its `.i64` from the sidecar to
+  reload with new options.
+
 ## Decisions
 
 - Residency is a **memory budget** (default 25% of RAM, `memory_pct`), not a