Import the wilm agent store and WINC adoption work, with four fixes

Eleven commits from the sister site: a reversible Maximo/WINC machine-adoption
import, a versioned agent binary store with upload and rollback, remote-BuildKit
CI, tray version reporting, and UI fixes. Applied as a patch again - the
published mirror rewrites hashes, so the branches have unrelated histories and
git refuses to merge them.

Reviewed by three agents before merging. Four things fixed here.

THE PUBLISH WORKFLOW WAS DEAD. The new remote-BuildKit step in
publish-images.yml sits at column 0 instead of indented under steps:, so the
whole file is invalid YAML and GitHub would refuse it. Their entire GHCR
distribution channel - which Start-ShopDBDev.ps1 and the compose files consume -
was broken at the source and clearly never run. Indented; all five workflows now
parse.

THE IMPORT'S APPROVAL CHECK COULD NOT FAIL. commit() built the plan and the
approval packet from the same upload and then asked the writer whether they
matched, so packet_matches_plan compared a hash against itself. The documented
contract - "a human approves a specific, frozen plan, and the writer can prove
nothing drifted" - did not exist in the web path: an admin could preview file A
and commit file B, gated only by the needs-create group NAMES they ticked. The
preview's planhash is now required at commit and checked against a freshly
rebuilt plan. Their tests committed without previewing, which is what let this
through; they go through the real flow now, and three new tests pin it - all
confirmed to fail with the check stubbed out.

endpoints.agentpackage QUIETLY GREW. It used to mean "wrap the staged exe in a
ZIP"; with the upload routes it also means "choose the executable every future
package installs and runs as SYSTEM". Before this, staging needed filesystem
access to the server. The permission description still said only "generate and
download a package", so an admin granting it could not see what they were
granting. Reworded.

NOTHING RECORDED WHAT WAS STAGED, OR BY WHOM. The manifest held version, size
and timestamp; re-uploading a version replaces the bytes in place under the same
label. A sha256 of the stored file is now recorded, and the upload is
audit-logged with it - after an incident there was previously no answer to who
put that binary on the fleet.

Also documented the nine new routes in docs/api-inventory.json (that gate cannot
run on the mirror, so it falls to us at promotion time again), regenerated the
spec and the project map, and kept our own docs where they conflicted: docs/ is
scrubbed from the mirror, so their DEV-BUILD-TEST.md still had the dev-be
channel mapping we corrected, and their PLUGIN-HOOKS.md was a new 45-line file
rather than our 737-line canonical one. Their journal section is appended to
ours.

Contract version comes across as 0.30.0 for a genuinely additive surface.

Suite 2369, frontend 324, gate green.

Scope: product

docs/PLUGIN-HOOKS.md

@@ -735,3 +735,41 @@ When you change anything documented here, you must:
 3. Add or update the test in `tests/test_plugin_contract.py` that asserts the new behavior.
 
 The skill `defining-asset-contract` walks through the full checklist.
+
+## Reversible bulk-import journal
+
+Contract version 0.30.0.
+
+A plugin that drives a bulk import - a site asset adoption, an integration sync -
+records the primitive changes it makes so the whole batch can be reversed later.
+The journal is import-agnostic: it stores primitive mutations (set a cell, insert
+a row) tied to a batch id, and a generic undo replays them in reverse. Nothing in
+core learns what the import means.
+
+Exposed on `shopdb.api`:
+
+- `ImportBatch` - one row per applied import. `batchid` is the identity that the
+  approval step, the write, and the undo all reference. `status` is `applied` or
+  `undone`.
+- `ImportJournalEntry` - one reversible primitive mutation. `operation` is
+  `update` (a cell change, carrying `oldvalue`/`newvalue` so it can be put back)
+  or `insert` (a row this batch created, so undo can delete strictly what the
+  import created).
+- `BATCH_APPLIED`, `BATCH_UNDONE` - the two `ImportBatch.status` values.
+- `OP_UPDATE`, `OP_INSERT` - the two `ImportJournalEntry.operation` values.
+
+What a plugin gets from this, and what it does NOT:
+
+- A plugin's import UI reads `ImportBatch` to list applied batches (kind, row
+  count, who applied it, when) and offers an "Undo import" per batch.
+- A plugin does NOT write the journal or run undo through these model imports.
+  The write/undo logic lives with the import writer (see
+  `scripts/site_imports/journal.py`), which records entries in the SAME
+  transaction as the mutation they describe and reverses them conservatively:
+  an `update` is put back only if the cell still holds the value the import
+  wrote (a value a human changed since is left as-is and reported), and an
+  `insert` is hard-deleted only when nothing outside the batch still references
+  the created row.
+
+The tables are core-owned (migration `7d37_import_batches_and_journal`), so they
+exist regardless of which plugins are installed.