Consolidate the duplicated enabled-sync pattern across motor modules

[JensOgorek]

Follow-up from the #225 review (finding 5, explicitly out of scope for that behavior-preserving split).

#225 gave the enabled-sync pattern (edge-detecting direct writes to the enabled property in step() plus the dual bookkeeping of member and property in enable()/disable()) a shared home in the Wheels base class — but five motor modules still carry their own copies:

• d1_motor.cpp (~line 149)
• dunker_motor.cpp (~line 188)
• linear_motor.cpp (~line 40)
• mks_servo_motor.cpp (~line 186)
• canopen_motor.cpp (~line 562)

The copies differ in details, so hoisting into Module (or an intermediate base/mixin) needs some design work:

• CanOpenMotor guards the sync with its initialized flag and performs an extra property write.
• The motor modules gate their speed/motion commands on the member (one-cycle lag after a direct property write), whereas the wheels modules now deliberately gate on the immediate property — consolidation should either reconcile this or keep the gate out of the shared part.

Goal: the next enabled-capable module shouldn't have to add a seventh copy.