Make the legacy import safe to resume, and aimable without editing it

Three defects broke the loader's own documented resume guarantee. All three
were silent: nothing raised, the run finished cheerfully, and fewer rows
arrived than anyone counted.

THE PAGE SIZE WAS CLAMPED, SO THE 409-RESOLVE SEARCHED THE FIRST 100 ROWS

_upsert asked for ?per_page=10000 and read one response. The server clamps any
page size to MAX_PAGE_SIZE, which is 100 - not an error, not a warning, just
100 rows. Anything past that resolved to None, so the id never reached the
crosswalk and the run quietly dropped a model's link on every machine that used
it, or an application's installs.

The target already holds more than 100 models and more than 100 applications,
so this fired on any re-run or resume - exactly the case the loader documents
as safe.

_resolve_existing now tries the exact natural-key filter the API has exposed
all along (?modelnumber= on models, ?appname= on applications, ?vendor= on
vendors) and then pages properly, bounded. An endpoint without such a filter
ignores the unknown parameter and the paged walk finds the row.

stage_metrology repeated the same mistake in its own way: it skipped 409s
entirely, so a resumed run left the tool out of the crosswalk and the Controls
edge unmade - metrology PCs driving nothing. stage_printers already had the
resolve branch; that stage was written later and missed it.

THE CROSSWALK WAS NOT BOUND TO THE DATABASE IT DESCRIBED

idmap.json maps this site's legacy ids to assetids in ONE database, and those
assetids mean nothing anywhere else. Keeping it across a drop-and-rebuild left
warranties and printer assignments attaching to whatever asset now holds that
id: wrong data, no error. The runbook's two "drop and rebuild" steps never
mentioned the file.

The loader now writes a uuid marker into the TARGET's own settings table, so it
dies with the data, and stamps it into the crosswalk. A crosswalk built against
a different database is refused before a row is written. The database name
alone would not do - a rebuild keeps the name. A file written before this guard
is adopted rather than refused, so no existing crosswalk is stranded.

Also adds --idmap, so one checkout can drive more than one target.

THE SOURCE DATABASES ARE NAMED, NOT HARDCODED

'shopdb_src' appeared at 29 call sites, so aiming the loader at the prodscratch
restore meant editing run.py. Those names are now LOGICAL and resolved in
Source.db() from SOURCE_DB_MAIN / SOURCE_DB_USB / SOURCE_DB_EMPLOYEES, with
host, port, user and password overridable too. The call sites are untouched -
resolving centrally avoids missing one, and the literals now read as
documentation of which source a stage draws from. The run prints every source
it redirected, so "it imported nothing" can be told apart from "it read the
wrong database".

This is what stood between the loader and the prodscratch run.

TWO SMALLER ONES

_source_password() raised IndexError rather than its intended message whenever
the DATABASE_URL user is not root, which it will not be on a real server.

main() returned 1 on failure into a caller that discarded it. A run that logged
200 endpoint errors exited 0 and read as a success in a deploy log; it now
exits non-zero.

TESTS AND DOCS

The loader had no tests at all. Sixteen now cover the resolve, the crosswalk
binding and the source aliasing - the logic that can run without a MySQL
source, which is the part that was wrong. Verified they are not vacuous by
running the old algorithm against the same fixture: it returns None where the
new one returns the row.

The README claimed 15 stages "complete" with counts from 2026-07-13 that two
later routing changes invalidated, and the runbook told operators to verify a
fresh import against them. Both corrected, with the three gaps NOT fixed here
recorded plainly: warranties, notifications and knowledgebase POST without a
duplicate check so resuming across them doubles rows; there is no --dry-run or
target guard; and the verify stage counts target assets against source machines,
which is apples to oranges.

Full suite 2178 passed.

scripts/site_imports/wjf/PILOT-DEPLOY.md

@@ -78,9 +78,36 @@ import API. It is site glue, not product code.
      venv/bin/python -m scripts.site_imports.wjf.run
    ```
 
-   The 16 stages run in order (reference -> catalog -> assets hub -> locations ->
-   printers -> dependents -> relationships -> subnets -> usb -> verify). It is
-   idempotent - a crashed run resumes from `idmap.json`.
+   The 17 stages run in order (reference -> employees -> catalog -> assets hub
+   -> locations -> printers -> metrology -> communications -> applications ->
+   warranties -> notifications -> knowledgebase -> relationships ->
+   defaultprinters -> subnets -> usb -> verify).
+
+   **Pointing it at a different source.** The three source databases are
+   named logically in the loader and resolved from the environment, so a
+   restore under another name needs no code edit:
+
+   ```
+   SOURCE_DB_MAIN=prodscratch \
+   SOURCE_DB_USB=cmmc_usb_src \
+   SOURCE_DB_EMPLOYEES=wjf_employees_src \
+   DATABASE_URL=... venv/bin/python -m scripts.site_imports.wjf.run
+   ```
+
+   Also `SOURCE_DB_HOST`, `SOURCE_DB_PORT`, `SOURCE_DB_USER`,
+   `SOURCE_DB_PASSWORD`. The run prints every source it redirected, so
+   "it imported nothing" can be told apart from "it read the wrong database".
+
+   **Resume is per target database.** A crashed run resumes from the crosswalk
+   in `idmap.json`, which maps this site's legacy ids to assetids **in one
+   specific database**. The loader stamps that database's identity into the
+   file and refuses a crosswalk built against a different one, because reusing
+   it attaches warranties and printer assignments to whatever asset now holds
+   that id - wrong data, no error. If you rebuild the target, delete
+   `idmap.json` or pass `--idmap` a fresh path.
+
+   The exit code means something: non-zero if any endpoint errored, so a run
+   that logged 200 failures cannot read as a success in a deploy log.
 
 3. Reclassify servers into network devices. The classic DB stored servers as
    PCs, so the import lands them as `computer` assets. Re-point them in place:
@@ -151,8 +178,12 @@ documented skips (inactive rows, duplicate machinenumbers, LocationOnly, the
 - Keep the classic app authoritative during the window. The pilot is read-mostly
   for validation; do not dual-write.
 - Have a few real users (IT + a floor lead) work the pilot and log gaps.
-- Re-import is cheap: fix a loader mapping, drop + rebuild the pilot DB, re-run.
-  Nothing you do to the pilot touches classic.
+- Re-import is cheap: fix a loader mapping, drop + rebuild the pilot DB,
+  **delete `idmap.json`**, re-run. Nothing you do to the pilot touches classic.
+  The crosswalk is bound to the database it was built against and the loader
+  refuses a stale one, but deleting it is the habit to have - a refusal costs
+  you a restart, and before the guard existed a stale file silently attached
+  rows to the wrong assets.
 - Point the **collector** (GE-Enforce fleet ingest) at the pilot in parallel to
   confirm live PC check-ins land (see `COLLECTOR-INTEGRATION.md`), using a
   scoped service token.
@@ -163,7 +194,7 @@ When the window is clean:
 
 1. Freeze classic writes (announce a short read-only window).
 2. Take final fresh dumps; re-run the loader into a clean pilot DB so the
-   cutover data is current.
+   cutover data is current. A clean DB means a fresh `idmap.json` too.
 3. Verify counts + a fast UI spot-check.
 4. Repoint the production hostname/DNS (or the reverse proxy) at the pilot.
 5. Retire the classic app to read-only standby (do not delete - keep it as the