Stop the collector being able to set a printer assignment

The printer feature rests on one rule: a collector report is OBSERVED state and
never ASSIGNED state. If a drifted bay's own state can become what it is told to
install, enforcement stops meaning anything, because a bay that installed the
wrong printer makes itself right simply by reporting it.

_sync_printer_links broke that rule. It ran on every collector PC push and, when
the payload carried defaultprinter or printers, wrote defaultprinter and
connectedto rows from the report - defaultprinter being one of the two types
_reconcile_edges is meant to own alone, from authenticated routes a human calls.

It was recorded as dormant. It was not. The collector schema ADVERTISED both
keys and the example client in COLLECTOR-INTEGRATION.md set
$payload['defaultprinter'], so the documentation was recruiting callers for it -
while the same document, under "Observed is not assigned", promised that nothing
on this path writes a usesprinter or defaultprinter row. The document
contradicted itself and the code followed the wrong half. Nothing in the fleet
armed it, because the first-party reporter never sent those fields, but any
third-party client written from the docs would have.

Retired the function, its _sync_one helper and the now-unused
PRINTER_LINK_ORIGIN label, and removed both keys from the schema.

IGNORED, NOT REJECTED. Unknown payload keys are not validated, so a client
written against the old docs keeps pushing successfully and only its printer
keys stop doing anything. The response warns, naming the keys and pointing at
POST /api/collector/printers for reporting queues and seed-from-observed for
adopting them. Dropping them in silence would leave an integrator believing
assignments were still being written, which is a worse failure than the one
being fixed.

The docs were the larger half of this. The schema table rows are gone, the
"PC -> printer relationship sync" section is replaced by a note saying what
happens now to anyone still sending the keys, and the example client no longer
enumerates Win32_Printer at all - it points at Report-PrintersToShopDB.ps1,
which posts to the observed endpoint and posts NOTHING on a failed enumeration,
since an empty list would erase the host's rows.

test_collector_printers.py pinned the old behaviour, so it now pins the
opposite: the keys create no relationships, the push still succeeds and says
why, a payload without them stays quiet, a human-made default survives a report
naming a different printer, and the schema no longer offers the keys.

docs/COLLECTOR-INTEGRATION.md

@@ -214,8 +214,6 @@ a column.
 | `modelnumber` | string | `Computer.modelnumberid`, scoped to the vendor when known. Model row auto-created if missing. |
 | `osname` | string | `Computer.osid`. Controlled vocab: looked up in `operatingsystems`, NOT auto-created. Unknown value -> warning (row still written, `osid` left unset). |
 | `installedsoftware` | array of `{name, version}` | `ComputerInstalledApp` rows for applications shopdb already tracks. Unknown app name -> warning, skipped. |
-| `defaultprinter` | string | The default printer's identifier (windows name / share / hostname / port IP). Resolved to a printer asset and linked PC -> printer as a `defaultprinter` relationship. Unresolved -> warning. |
-| `printers` | array of strings | All installed network printer identifiers. Each resolves to a printer asset and is linked PC -> printer as a `connectedto` relationship (the default is skipped here since it already links as `defaultprinter`). Unresolved entries -> warning. |
 
 Schema source of truth: `get_collector_schema` in `plugins/computers/plugin.py`.
 If you change the payload, change it there and re-check this table.
@@ -313,31 +311,20 @@ because several markers serve one operation. Naming the marker in `asset-id.txt`
 changes which marker asset the PC controls; it does not change which operation
 that marker files under.
 
-### PC -> printer relationship sync
+### PC -> printer relationship sync (REMOVED)
 
-When a payload carries `defaultprinter` and/or `printers`, the collector syncs
-`AssetRelationship` rows so a PC page shows its printers and a printer page shows
-the PCs that use it (both render in the shared Relationships card).
+**A collector report has never been allowed to set a printer assignment, and as
+of 2026-08-24 it no longer can.** `defaultprinter` and `printers` used to be
+accepted here and written as `defaultprinter`/`connectedto` relationship rows.
+That contradicted the rule stated under "Observed is not assigned" below, and
+this document carried both claims at once while the code followed the wrong one.
 
-- Resolution: each identifier is matched, first hit wins, against the printer's
-  `windowsname`, `hostname`, `sharename`, its asset number/name, then any active
-  printer communications IP. Case-insensitive except the IP (exact). An
-  identifier that resolves to nothing adds a warning and is skipped; it never
-  fails the whole push.
-- Link types: the default printer links with `defaultprinter` (directional, PC
-  is the source); every other reported printer links with `connectedto`
-  (symmetric). A printer that is both default and in `printers` links only as
-  the default.
-- Idempotent: re-reporting the same set creates no duplicate rows (an existing
-  matching row is reactivated if it was archived, otherwise left as is).
-- Stale-link archive: on every push, collector-created links to printers no
-  longer reported are set inactive. Collector-created rows are tagged in
-  `assetrelationships.label = 'collector:printers'`; only tagged rows are ever
-  archived, so links you create by hand in the UI are never touched. A payload
-  that omits BOTH printer keys leaves all existing printer links untouched
-  (report an empty `printers: []` to clear the auto links instead).
-- Response: the collector response carries `printerlinkcount` and a
-  `printerlinks` list of `{assetid, relationshiptype}` for the links kept.
+If you are still sending either key: **your push still succeeds** - they are
+ignored, and the response carries a warning naming them. Nothing else about your
+payload changed. To report what a PC actually has, use
+`POST /api/collector/printers`; to turn that into an assignment, a person calls
+`POST /api/printers/assignments/seed-from-observed/<assetid>` after reviewing the
+comparison.
 
 ### pc-type mapping (configurable per site)
 
@@ -766,32 +753,15 @@ function Send-ShopdbCollectorReport {
         try { $pcSubType = (Get-Content -LiteralPath 'C:\Enrollment\pc-subtype.txt' -First 1 -ErrorAction Stop).Trim() } catch {}
     }
 
-    # --- Installed printers (Win32_Printer). The Default flag marks the one
-    # default printer. We report each printer's port name (an IP or a queue
-    # host for network printers) and fall back to the share/printer name, which
-    # the collector resolves flexibly against printer windowsname/hostname/IP. ---
-    $defaultPrinter = ''
-    $printerIds     = @()
-    try {
-        $printers = Get-CimInstance -ClassName Win32_Printer -ErrorAction Stop
-        foreach ($p in $printers) {
-            if ($p.Local) { continue }   # skip local-only (XPS/PDF/OneNote)
-            # Prefer the port name (IP or queue host); fall back to ShareName,
-            # then the printer Name.
-            $identity = $p.PortName
-            if (-not $identity) { $identity = $p.ShareName }
-            if (-not $identity) { $identity = $p.Name }
-            if (-not $identity) { continue }
-            $printerIds += $identity
-            if ($p.Default) { $defaultPrinter = $identity }
-        }
-        $printerIds = @($printerIds | Select-Object -Unique)
-    } catch { Write-CollectorLog "WARN printer read failed: $($_.Exception.Message)" }
+    # --- No printer enumeration here, on purpose. This example used to collect
+    # Win32_Printer and send defaultprinter/printers, which wrote ASSIGNMENT
+    # rows from a report - the one thing this path must never do. Report what a
+    # PC has to POST /api/collector/printers instead (Report-PrintersToShopDB.ps1
+    # in the printers plugin does exactly that, and posts NOTHING when the
+    # enumeration fails, because an empty list would erase the host's rows). ---
 
     # --- Build payload. Field names MUST match get_collector_schema exactly. ---
     $payload = @{ hostname = $hostname }
-    if ($defaultPrinter)   { $payload['defaultprinter'] = $defaultPrinter }
-    if ($printerIds.Count) { $payload['printers']       = $printerIds }
     if ($machineNumber) { $payload['machinenumber'] = $machineNumber }
     if ($deviceId)      { $payload['deviceid']      = $deviceId }
     if ($pcType)        { $payload['pctype']        = $pcType }

docs/PROJECT-MAP.md

@@ -36,6 +36,7 @@ with `flask plugin upgrade-all`. Both are needed on a deploy.
 | printedparts | `printedparts0004txnrev` |
 | printers | `printers0005observedqueues` |
 | slides | `slides0001anchor` |
+| tools | `tools0001securesend` |
 | usb | `usb0002dropmachineid` |
 | warranty | `warranty0002proof` |
 
@@ -55,7 +56,7 @@ with `flask plugin upgrade-all`. Both are needed on a deploy.
 | printedparts | 0.1.0 | >=0.16.0,<1.0.0 | yes |
 | printers | 1.0.0 | >=0.20.0,<1.0.0 | yes |
 | slides | 2.0.0 | >=0.2.0,<1.0.0 | yes |
-| tools | 1.0.0 | >=0.16.0,<1.0.0 | no |
+| tools | 1.0.0 | >=0.16.0,<1.0.0 | yes |
 | usb | 1.0.0 | >=0.1.0,<1.0.0 | yes |
 | warranty | 1.0.0 | >=0.2.0,<1.0.0 | yes |
 
@@ -85,6 +86,6 @@ Manifest-less directories under `plugins/` are core frontend surface and always
 
 ## Size
 
-- test functions defined: **1140** (parametrised cases collect higher)
-- documented API paths: **282** (`docs/openapi.json`, regenerate with `scripts/gen_openapi.py`)
+- test functions defined: **1233** (parametrised cases collect higher)
+- documented API paths: **285** (`docs/openapi.json`, regenerate with `scripts/gen_openapi.py`)