computers: a part marker is its own asset, under the operation it serves

Several Telesis markers serve one operation number - 0613, 0615 and WJPRT each
have more than one - so treating the operation as the marker collapsed separate
devices into a single record. Their configurations differ by COM port, so in
the backup history they overwrote each other, and no question about an
individual marker could be asked at all: how many there are, which port one is
on, which one failed.

There is one marker per PC, which makes the PC the marker's identity, so the
collector can mint the marker the same way it already mints a CMM or a Keyence
unit for a metrology PC. A marker PC now gets a Part Marker machine asset, the
PC controls it, and the marker is partof the operation whose number the PC
reports. An operation holds any number of markers.

A marker PC therefore does not claim the operation directly. controls
propagates through partof, which reference-data already seeds, so control of
the operation still follows from controlling its marker - without two markers
contesting a link only one of them can hold.

Backups from a marker PC resolve to the marker rather than the operation, and
fall back to the machine number whenever the marker cannot be resolved: no
hostname on the payload, a lean build without the computers or machines plugin,
or a marker PC that has not reported to the computers collector yet. Filing
under the operation is the old behaviour and beats rejecting a backup.

Moving a marker to another operation archives the old membership rather than
deleting it, so where a marker used to live stays answerable.

CHANGELOG.md

@@ -83,6 +83,20 @@ 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 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,
+  overwrote each other in the backup history, and no question about an
+  individual marker - how many there are, which port one is on, which one
+  failed - could be asked at all. There is one marker per PC, so the collector
+  now mints a Part Marker machine asset for a marker PC the same way it already
+  mints a CMM or a Keyence unit for a metrology PC: the PC `controls` the
+  marker, and the marker is `partof` the operation it serves. Because `controls`
+  propagates through `partof`, control of the operation still follows from
+  controlling its marker, and two markers on one operation no longer contest a
+  link only one of them can hold. Backups from a marker PC file against the
+  marker. Moving a marker to another operation archives the old membership
+  rather than deleting it.
 - Plugin contract 0.16.0: `get_settings_defaults()` lets a plugin declare the
   settings it owns (key, default, type, category, description, and whether an
   unauthenticated caller may read it). See `docs/PLUGIN-HOOKS.md`.