Add reversible Maximo/WINC machine-adoption import

Machine data arrives as a Maximo asset export (validated against the WINC
site) that must update existing machines in place, not create canonical
per-table rows, so it does not fit the ShopDB-native/Azure/Thor CSV adapter
path. Bulk edits to live machines also need an escape hatch, so the whole
commit is journaled and can be undone as one batch.

Add a dedicated dry-run analyzer, approval packet, resolver/suggest helpers,
and a reversible writer/undo backed by a new importbatches/importjournalentries
schema (with migration). Expose preview/commit/batches/undo settings routes and
a matching frontend source card and panel, and surface the batch/journal
contract through shopdb.api for plugins.

scripts/site_imports/winc/aliases.py

@@ -0,0 +1,67 @@
+"""Alias and normalization tables for the WINC machine adoption dry-run.
+
+This file is DATA, not logic. It is the single place a human edits when the
+analyzer reports an unresolved value. Keep it boring: plain dicts, one entry per
+line, lowercase keys. The analyzer lowercases and strips before it looks a value
+up here, so keys here must be lowercase and already stripped.
+
+Two independent problems get solved here:
+
+1. eq1 -> business unit. The May export's eq1 column is a free-text value-stream
+   label (LG PARTS, SM SPOOLS, Large Spoo, HPTCR ...). It is dirty: truncated at
+   ten characters, inconsistently cased, and it does NOT match anything in the
+   live businessunits table (that table is a list of offices auto-created by an
+   earlier printer import). So every eq1 value must be mapped by hand to the
+   canonical business-unit name we want on the asset. A canonical name that does
+   not yet exist in the database is reported by the analyzer as "would need to
+   be created" - the analyzer never invents one and never writes one.
+
+2. location code overrides. Most WM-<bay> codes resolve by simply dropping the
+   WM- prefix and matching a location by name (WM-J3 -> J3). A handful do not,
+   because the bay code carries a slash, a note in parentheses, or a room name
+   the location table spells differently. Those exceptions - and only those -
+   live here, mapping the RAW export location string to the exact locationname
+   already in the database.
+"""
+
+# eq1 (lowercased, stripped) -> canonical business unit name.
+# The value on the right is what we intend to store; the analyzer checks whether
+# it already exists in businessunits and flags the ones that do not.
+EQ1_TO_BUSINESSUNIT = {
+    'lg parts': 'Large Parts',
+    'lg part': 'Large Parts',
+    'large part': 'Large Parts',
+    'sm spools': 'Small Spools',
+    'sm spool': 'Small Spools',
+    'large spoo': 'Large Spools',
+    'lg spools': 'Large Spools',
+    'lg spool': 'Large Spools',
+    'hptcr': 'HPT Rotor',
+    'bliskcr': 'Blisk Rotor',
+    'blisk': 'Blisk Rotor',
+    'leap x': 'LEAP-X',
+}
+
+# Raw export location string (lowercased, stripped) -> exact locationname in DB.
+# Only for codes that do NOT resolve by dropping the WM- prefix. Leave a value
+# as None to say "known to be unmappable, do not touch location for this row".
+#
+# The entries below the two None rows were promoted from the dry-run's
+# high-confidence suggestions and verified to exist in the locations table. A
+# slash-joined bay code (T6/U6) names two adjacent bays, but an asset carries a
+# single locationid, so each maps to the FIRST (primary) bay - the deterministic
+# choice a human confirmed. LD7W and LD6W are intentionally absent: they had no
+# existing match and need a location created before they can be aliased.
+LOCATION_OVERRIDES = {
+    'wm': None,
+    'wm-toolroom': None,
+    'wm-t6/u6': 'T6',
+    'wm-t9/10': 'T9',
+    'wm-u9/10': 'U9',
+    'wm-t4/u4': 'T4',
+    'wm-ld9w(ge90)': 'LD9W',
+    'wm-m6.3': 'M6',
+    'wm-l1-4': 'L1',
+    'wm-ld7w': None,
+    'wm-ld6w': None,
+}