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/README.md

@@ -33,16 +33,34 @@ resolved decisions, and remaining stages.
 
 ## Status
 
-Complete - all 15 stages built and verified end-to-end against a fresh scratch
-target (zero endpoint errors): `reference`, `employees`, `catalog`, `assets`
-(the hub + machineid->assetid crosswalk), `locations`, `printers`,
+All 17 stages built: `reference`, `employees`, `catalog`, `assets` (the hub +
+machineid->assetid crosswalk), `locations`, `printers`, `metrology`,
 `communications`, `applications` (+ installs), `warranties`, `notifications`,
-`knowledgebase`, `relationships`, `subnets`, `usb`, `verify`.
+`knowledgebase`, `relationships`, `defaultprinters`, `subnets`, `usb`, `verify`.
 
-Last full run: 983 assets (computer 663, machine 76, network 58, measuring-tool
-136, printer 50), 24 locations, 415 employees, 850 installs, 461 primary IPs,
-464 warranties, 261 notifications, 341 KB, 93 relationships, 37 subnets, 18 USB
-devices + 232 events. UI spot-check passed (computer list + shop-floor map).
+**The counts below are from the 2026-07-13 run and are STALE.** Two routing
+changes landed after them - the `isactive=1` filter and the metrology routing
+rework - so the asset mix has moved substantially. They are kept only as a
+shape, not as a checklist: re-measure from the next full run before quoting
+them anywhere, and do not verify a fresh import against them.
+
+Last full run (2026-07-13, superseded): 983 assets (computer 663, machine 76,
+network 58, measuring-tool 136, printer 50), 24 locations, 415 employees, 850
+installs, 461 primary IPs, 464 warranties, 261 notifications, 341 KB, 93
+relationships, 37 subnets, 18 USB devices + 232 events.
+
+Known gaps, none of them blocking a scratch run:
+
+- `warranties`, `notifications` and `knowledgebase` POST without a duplicate
+  check on the API side, so resuming ACROSS one of those stages doubles its
+  rows. Resuming at or after them is safe. Re-run into a clean target when in
+  doubt.
+- There is no `--dry-run` and no guard on the target: the harness mints an
+  admin PAT and sets `setup_complete` in whatever `DATABASE_URL` points at.
+  Check the target before running.
+- The `verify` stage counts target `assets` against source `machines`, which is
+  apples to oranges - the target also holds printers and synthesized metrology
+  tools.
 
 Known follow-ups: general asset `locationid` is null (no source column outside
 printers); the ~146 duplicate machinenumbers are first-wins-skipped by decision.