Find the import table from the calls when no directory describes it

A captured image often has no import data: the descriptor is gone, the IAT directory is
gone, and nobody took a write watch. The table is still findable, because the rewrite left
a relation behind -- the slot holds the address the call targets -- so the call sites
become the search key.

discover_iat scans the non-executable sections for pointer-aligned entries equal to the
target of a relative call that leaves the image, then clusters the matches by proximity.
One cluster is used and its span becomes the inventory. Two are printed and refused: a
duplicated table, a copied table and a table split by a section boundary all look like
this from the outside, and picking one produces a file that loads and calls the wrong API
for one import. A single match is called weak rather than used.

Discovery runs when the described slots explained none of the calls, not only when the
inventory came back empty -- a protector that leaves a plausible-looking but useless
descriptor is the case the narrower rule missed. --iat suppresses it because that is the
reader asserting the range, and --no-discover is the control that keeps "the search
worked" from being a statement about the fixture.

walk_sites and pair_sites replace the single scan-and-pair pass, because discovery needs
the targets before any slot exists and one function could not express that order.
decide_result gains ambiguous-iat, which exits 1 like the other two verdicts that mean
this run did not finish the job.

Tests: the same image with its slots outside every directory recovers the two pairs the
explicit range produced; the control with --no-discover still reports needs-trace; a
second copy of the table in another section is refused with its own token; and a search
that matched nothing says so instead of reading as a clean image.

The reference gains the search, its two refusals, and the pair of failures that look
identical from the report -- slots holding tags have no value relation to search, and a
wrong base finds nothing either, so the base is checked first.

docs/tool-verification/EXTENSION-absorption-themida.md

@@ -48,7 +48,10 @@ its own subject in one place can be wrong in another, and the wrong part does no
 - **`references/environment.md`**: the compatibility-shim fact, because it changes what "it ran
   once" means and it lives in neither file.
 - **`scripts/iat_callsite_restore.py`** with a unit and a CLI layer, registered in the capability
-  registry as `call_site_restore`.
+  registry as `call_site_restore`. Its table search is the offline counterpart of the unpacker's
+  IAT-location routine, derived from the relation the rewrite leaves behind — the slot holds the
+  address the call targets — and not from that routine's code; the search refuses two candidate
+  tables, where that routine would have taken the run it found first.
 
 ## What was deliberately not asserted