docs: write down the composition pattern, not just the one case

The MECHANISM was already a documented platform contract - ADR-001 defines
partof as composition, makes controls propagate through it, and walks it first
for map-position inheritance. The part-marker work used that rail rather than
inventing one.

What was undocumented is the PATTERN built on it: several devices answering to
one identifier, each becoming its own asset filed under a parent. It existed
only as a collector behaviour for part markers plus a docstring in the device
map, so nothing told anyone how to apply it to another device type, or when not
to.

ASSET-COMPOSITION.md covers when to reach for it and when the shared identifier
is a numbering fault instead, what propagation buys, how to declare a device
type through the map or a per-site setting, what a backup kind must do to
follow the device rather than the parent, how to find the next case with
check-shared-machines, and why the parent is not disposable once devices hang
off it - deactivating it breaks filing, and a hard delete cascades through
backuprevisions.

docs/COLLECTOR-INTEGRATION.md

@@ -246,6 +246,11 @@ A PC takes its hostname as its asset number and keeps it.
   several PCs on one machine number legitimately, and there the alerts fire on
   correct data. Warnings ride in the collector response either way.
 
+The part-marker case below is one instance of a general pattern - several
+devices under one parent. `docs/ASSET-COMPOSITION.md` covers when to use it,
+what propagation buys you, and how to declare a new device type without a code
+change.
+
 A PC reporting `pctype = gea-shopfloor-partmarker` is handled differently,
 because several markers can serve one machine number and an operation holds any
 number of them. Such a PC gets its own Part Marker machine asset