computers: declare subordinate devices instead of coding each one

A PC that drives a device which is its own asset had been implemented twice.
METROLOGY_TOOL_MAP covered CMM, Keyence, Genspect and wax-trace, minting a
measuring_tool. A separate path keyed on one hardcoded pc-type minted a Part
Marker machine and filed it under its operation. Both create a device, link the
PC with controls, and archive that link when the PC is re-imaged: one mechanism
with different nouns, written out twice because the second case arrived later.

That is the same trap as the site literals in ADR-015 - a pattern implemented
per instance rather than declared - and it has a known next occurrence. Part
markers already share operation numbers, and any site with two marking lasers
or two wax-trace units on one number needs identical treatment.

One SUBORDINATE_DEVICE_MAP now declares asset type, type name, naming suffix,
whether the device files partof the operation, and the relationship label. The
labels are unchanged per case on purpose: those values are in the production
database and only rows carrying them are archived by a collector push. A site
overrides or adds an entry through subordinatedevice_<pctype> settings, per
ADR-015, so the next case needs no code. A malformed override falls back to the
default rather than failing the push, because a bad setting must not stop a bay
reporting its inventory.

metrology_tool_for stays as a shim over the same map: filters.py and the older
tests read it, and unifying must not change what it returns. A test pins that.

Also adds flask relationships check-shared-machines, which finds the next 0615
rather than waiting for someone to notice duplicate backups. Several devices
legitimately sharing a number and two PCs mis-numbered at imaging look the same
from outside; the difference is whether child assets exist, so that is what it
reports. Read-only.

CHANGELOG.md

@@ -88,6 +88,21 @@ ADR-007 and ADR-002.
   `computers_machinelink_alerts` setting that ships OFF: a site may legitimately
   run several PCs on one machine number, and there the alerts fire on correct
   data. The collector response warns either way.
+- A PC that drives a subordinate device is now declared, not coded. Two cases
+  had arrived separately and been written twice: a metrology PC drives a CMM or
+  Keyence unit that becomes a measuring-tool asset, and a part-marker PC drives
+  a marker that becomes a machine asset filed under its operation. Both mint a
+  device, link the PC with `controls` and archive that link on a re-image - one
+  mechanism with different nouns. They are now one map, and a site can add or
+  retarget an entry through a `subordinatedevice_<pctype>` setting, so the next
+  case - two marking lasers or two wax-trace units on one machine number - is
+  configuration rather than a code change. A malformed override falls back to
+  the default instead of failing the collector push.
+- `flask relationships check-shared-machines` reports machine numbers claimed
+  by more than one PC, and says which are modelled and which are faults. Several
+  devices genuinely sharing a number and two PCs mis-numbered at imaging look
+  identical from the outside; the difference is whether anything is filed under
+  the operation, which is what the check reports. Read-only.
 - A part marker is its own asset. Several Telesis markers can serve one
   operation number, so treating the operation as the marker collapsed separate
   devices into one record: their configurations, which differ by COM port,