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/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`)