Record who owns what, and report repo-vs-share drift

OWNERSHIP.md
Every expensive bug in this pipeline has had one shape: two systems setting the
same thing, last writer winning silently. Four happened on 2026-08-06 alone -
computer name (package vs run-enrollment), drive letters (PESetup vs a volume
finder), enrollment (package vs an at-logon -ManualFallback task that syspreped
finished machines), kiosk URLs (GE-Enforce vs site-config). Each is written down
with the evidence so the next person deletes a writer instead of adding one.

share-drift.py
The share is production and the repo is meant to describe it, but drift runs both
ways: live hand-edits nobody committed, and repo fixes never deployed. The
unattend outage lived only on the share while the repo copy was fine, and nothing
compared them.

Each mapped pair is classified. git-owned means the repo wins and the pair must
match - those fail the run. unreconciled means the two have genuinely diverged
and nobody has decided; reported, not failed. The unattends are unreconciled on
purpose: live is ~17 KB against ~12 KB in the repo, so a blind push would regress
production. Reads over SSH via base64 so BOM and CRLF survive the hop.

First run: 8 git-owned pairs all match, 4 known-unreconciled.

Run-ShopfloorSetup.ps1
Corrects a comment that was actively misleading. It claimed shopfloor PCs are
"vanilla by design" and that the orchestrator runs -ManualFallback to skip BPRT
injection and the package entirely. Shopfloor bays DO enrol - the SFLD package
joins Entra with its BPRT token and a human assigns the device category in
Intune. -ManualFallback runs sysprep /oobe /reboot, which is why wiring it to an
at-logon task destroyed the deployment chain.

The absent Entra wait is still correct, for a different reason: at that point the
bay is on the isolated PXE LAN with no route to Entra (579C144 held 172.16.9.81
and 172.24.19.142, neither in the production ranges). sync_intune retries until
the tech re-cables. "Entra ID Joined: false" right after imaging is normal.

docs/OWNERSHIP.md

@@ -0,0 +1,95 @@
+# Who owns what
+
+Every bug that cost a day in this pipeline has had the same shape: two systems
+both setting the same thing, and whichever ran last silently won. This file says
+who owns each concern so the next person deletes the loser instead of adding a
+third writer.
+
+All four examples below are real, from 2026-08-06.
+
+## Computer name - the PPKG owns it
+
+The provisioning package declares:
+
+```xml
+<DNSComputerName>F%SERIAL%</DNSComputerName>
+```
+
+so a bay comes up as `F<serial>`.
+
+`run-enrollment.ps1` used to also run `Rename-Computer -NewName "E$serial"`.
+Both are pending renames; last writer wins at reboot. The script ran twice, and
+its second run landed after the package had already queued `F579C144`, so the
+bay came up `E579C144` with the package reporting no errors at all.
+
+**Rule:** nothing in this repo renames a machine. If the naming convention
+changes, it changes in the package.
+
+## Drive letters - PESetup owns them
+
+PESetup hardcodes `W:` in nine places - every copy destination, both DISM
+offline sessions, `bcdboot`, `reagentc` - and creates it during its own disk
+preparation.
+
+`startnet.cmd` briefly had a volume finder that scanned for "the applied
+Windows volume" and `diskpart`-assigned it to `W:`. On a re-image it found the
+*previous* install, relabelled a partition PESetup was about to erase, and every
+staging copy failed into a volume that no longer existed.
+
+**Rule:** wait for `W:\Windows\System32\config\system` - the hive only exists
+once the WIM apply has written it. Never run `diskpart` while PESetup is
+running.
+
+See `docs/PESETUP-INTERNALS.md`.
+
+## Enrollment - the PPKG owns it, the orchestrator drives reboots
+
+The SFLD package joins Entra using the BPRT token in
+`0__Accounts_Azure.provxml`. A human then assigns the device category in Intune.
+
+The vendor's `Start-BulkEnrollOrchestrator.ps1` has two branches. The normal one
+aborts the package's own reboot, registers `AutoSecondReboot`, and drives the
+Entra join to completion. The `-ManualFallback` one runs `sysprep /oobe /reboot`
+- it is an interactive escape hatch for handing a machine back to OOBE, meant to
+be triggered by a person.
+
+The shopfloor unattend registered `-ManualFallback` as an at-logon scheduled
+task. So OOBE completed, autologon fired, and four seconds later the machine
+syspreped itself back to OOBE, losing the deployment chain permanently.
+
+**Rule:** shopfloor bays enrol. Never wire `-ManualFallback` to anything
+automatic.
+
+## Kiosk URLs - GE-Enforce owns them
+
+`plugins/geenforce/seed_display_scope.py` in shopdb-flask is authoritative:
+
+| display-type.txt | route |
+|---|---|
+| `Dashboard` | `/shopdb/shopfloor` |
+| `Lobby` | `/shopdb/tv` |
+| `3DPrintRoom` | `/shopdb/parts-kiosk` |
+
+Its dispatcher prefers the server-side role from Settings > Dashboard Defaults
+(resolved by device IP), falls back to `C:\Enrollment\display-type.txt`, writes
+the Startup shortcut itself, and **sweeps** any shortcut matching
+`shopfloor-dashboard` or `/shopdb/`.
+
+`site-config.json` also carries `edgeHomepage` per display type. Those are a
+backstop for the window before the kiosk installer runs - a stale value there
+gets deleted on the next enforce cycle rather than honoured.
+
+**Rule:** if a kiosk points at the wrong page, fix the GE-Enforce scope first.
+Keep `site-config.json` correct, but do not expect it to win.
+
+## Repo vs share
+
+The share is production; the repo is meant to describe it. Drift runs both ways -
+live hand-edits nobody committed, and repo fixes never deployed.
+
+`scripts/share-drift.py` classifies every mapped pair as `git-owned` (repo wins,
+safe to push) or `unreconciled` (diverged, nobody has decided). It reports and
+never writes. Run it before a build day; `scripts/preflight.py` covers the rest.
+
+The unattends are `unreconciled` on purpose: the live copies are ~17 KB and the
+repo copies ~12 KB, so pushing the repo would regress production.