Keep a site's own files when its container is replaced

`db_data` was a volume and the instance directory was not, so the documented
update path - `docker compose build api && up -d api` - recreated the container
and discarded everything the site had written. `plugins.json` is only the loud
part: maps, branding, model and application images, employee photos, warranty
proofs, slides, printed-part files and the Dell OAuth token all live under
instance_path too. MySQL rows survive and point at files that are gone, so the
second symptom is images 404ing rather than an error anybody sees.

Reported by an adopting site, which read it as having updated too fast. It had
not; nothing it could have done differently would have kept those files.

DEPLOY.md had been telling sites to back up `instance/` since it was written.
The template never gave them anything to back up.

The air-gap `migrate` service mounts the volume too, because
`flask plugin upgrade-all` rewrites plugins.json and that service exits
immediately after.

The image now creates instance/ ITSELF, owned by the app user. Docker seeds an
empty named volume from image content at the mountpoint, ownership included;
with no such directory in the image the mountpoint is created root-owned 0755
and the container, which runs as shopdb, cannot write into its own instance
directory. Caught by running the built image rather than by reading it: the
volume mounted clean and `touch` came back Permission denied. Verified fixed the
same way.

A stack that predates the volume needs its files moved across ONCE, while the
old container still exists - the volume is seeded from image content, and the
image ships instance/ empty, so it comes up empty rather than inheriting the old
container's writable layer. DEPLOY.md carries the procedure, including the chown
after `docker compose cp`, which writes files under the copying user's numeric
uid rather than the app user's.

Also here, found while checking what an upgrade actually runs: the connected
update steps ran `flask db upgrade` and stopped. Per-plugin Alembic chains
(ADR-008) are not part of that, so a connected site taking an image with a
bumped plugin migration ran the core chain and silently skipped every plugin
chain. The air-gap stack had it right all along. Both commands are in Step 9
now, plus a `db current` check against `db heads`.

CHANGELOG.md

@@ -10,6 +10,68 @@ ADR-007 and ADR-002.
 
 ## [Unreleased]
 
+### Added
+
+- **Printer assignment has a form.** `PrinterAssignmentPicker` is the ONE picker
+  for both ends: MachineForm gained it (the machine is where the assignment
+  belongs and there was no way to set it except the relationships card), and
+  PCForm now uses the same component instead of its own copy, so the two sides
+  of an override cannot drift. PCForm also stopped reconciling row at a time
+  through the generic relationship endpoints, which left a PC half-assigned on
+  an HTTP failure; it calls
+  `PUT /api/printers/assignments/for-asset/<id>` instead.
+- **A relationship type can declare itself singular**
+  (`relationshiptypes.issingular`, migration 7d34), and `defaultprinter` does.
+  Setting a second default REPLACES the first. The unique constraint is
+  (source, target, type), so two different targets were two valid rows and the
+  resolver took the OLDEST: a new default silently lost.
+- **Observed printer queues.** `POST /api/collector/printers` (the ADR-006 hook,
+  no new transport and no new credential) records what a bay ACTUALLY has in a
+  plugin-owned table, kept strictly apart from what it is assigned. Adoption is
+  explicit via `POST /api/printers/assignments/seed-from-observed`, which routes
+  through the same reconcile path as the editor and REFUSES a queue matching no
+  known printer. New client script `Report-PrintersToShopDB.ps1`.
+- **Wave-gated driver rollout.** `Install-ShopdbPrinterDrivers.ps1` takes
+  `-WaveStart`, `-Waves`, `-WaveUnit` and `-IgnoreWave`. GE-Enforce offsets each
+  PC by SHA256(hostname) % 5 MINUTES, which was sized for a JSON check, not a
+  100 MB driver set: ungated, ~300 bays pull ~30 GB inside one five-minute
+  window on the share the whole floor depends on. Each bay derives its wave from
+  its own hostname, the gate runs BEFORE the manifest is read (the manifest is
+  on that share too), and it fails closed on an unparseable date.
+
+### Fixed
+
+- **The image did not build.** `npm run build` fires a `prebuild` hook that runs
+  `node ../scripts/stage-frontend.mjs`, which stages each plugin's frontend into
+  the Vite tree and codegens `routes.gen.js`. The Dockerfile's frontend stage
+  copied `frontend/` alone and flattened it to the stage root, so that path
+  resolved to `/scripts` and every build since the staging script landed died on
+  `Cannot find module`. The stage now keeps the repo-relative layout and copies
+  `scripts/stage-frontend.mjs` and `plugins/` in beside it. Verified end to end:
+  16 plugin frontends staged, `frontend/dist` in the final image.
+- **The compose stack did not persist `instance/`.** `db_data` was a volume and
+  the instance directory was not, so `docker compose build api && up -d api`
+  recreated the container and discarded `plugins.json` along with every upload:
+  floor plans, branding, model and application images, employee photos,
+  warranty proofs, slides, printed-part files and the Dell OAuth token. The
+  visible symptom was a site coming back with its plugins disabled. Both compose
+  files now mount an `instance_data` volume (the air-gap `migrate` service too,
+  since `plugin upgrade-all` writes `plugins.json`), and DEPLOY.md carries the
+  one-time rescue for a stack that predates it.
+- **A drifted print queue is corrected, not just a missing one.** Queues were
+  matched by NAME alone, so a bay whose printer had moved or whose queue was
+  built on a replaced driver looked converged and printed to the wrong device.
+  `Set-ShopdbPrinters.ps1` now repoints a wrong port and swaps a wrong driver
+  IN PLACE with `Set-Printer`, so the queue keeps its name, sharing, permissions
+  and whoever holds it as their default. The driver is only swapped when the
+  wanted one is staged, and there is still no removal path in the script.
+- **MachineForm's dropdowns all came up empty.** It read `.data.data` off
+  `computersApi.listAll()`, which already resolves to the array, so the whole
+  parallel load threw into the catch and the machine's own values never loaded.
+- **The legacy import loader dropped `machines.printerid`**, the classic
+  system's record of each machine's default printer, so the production import
+  would have lost every one.
+
 ## [0.11.3] - 2026-08-19
 
 Fixes the last of the buildings-and-levels bugs, and brings the shop-floor