BM250_UF: converge the PropagationDistance motor onto the child-Asset nested-component convention

[xmap]

Follow-up to #162.

#162 set the identity-bearing component -> child Asset convention (Option C) and applied it to RotaryDriveChassis. The first nested-component case, the BM250_UF motor inside the PropagationDistance stage, predates that decision and is still a free-form descriptor blob:

deployments/2-bm/beamline.yaml:388

motor: { part: "Aerotech BM250_UF", type: "AC servo, 240 VAC", serial_number: "234848-07" }

BM250_UF is identity-bearing (own part + serial), so by the convention it should converge on the same shape: its own Asset (or the agreed nested-component representation) rather than an inline blob. Deliberately deferred from #162 to keep that PR scoped.

Trigger to act: when a third nested-component case arrives (the rule-of-three), design the general convention intentionally and back-migrate both BM250_UF and the RotaryDriveChassis interim onto it. Until then this tracks the known divergence so it is not lost.

[xmap]

Gating question for the operator (this single fact decides the model):

Is the BM250_UF motor field-replaceable on its own, or is it built into the PRO225SL stage as one unit?

• Independently swappable (own service life, can be exchanged without replacing the PRO225SL stage) -> it is a genuinely contained component -> model it as its own Asset, and we settle the "is Motor a Family" question at that point.
• Integral to the PRO225SL stage unit -> it is part of the stage, not a separate thing -> its serial 234848-07 is effectively the stage's serviceable serial; no separate Asset, and no new Family is invented.

Why this gates the work: the chassis (#162) slotted into the existing Housing Family, so it was a clean reuse. A bare motor has no Family, so modeling it separately would mean minting a new federation-shared Motor Family from a single instance (and implicitly inviting the ~89 other crate motors). We do not want to guess between "contained" and "integral" without this fact.

Until answered, BM250_UF stays as the inline descriptor note at deployments/2-bm/beamline.yaml:388 (not wrong, just under-structured).