[schedule] Clip/snap child items when a parent bar is moved

[mxatmx]

When a parent schedule bar is dragged or resized on the Production Schedule, prompt before clipping/snapping its child items to fit the new bounds, and apply (or revert) the change on confirm/cancel. Child original dates are stamped at drag start so a cancel restores them exactly.

[frankrousseau]

Review notes:

The clipping logic itself is sound: origin dates stamped at mousedown, restore-then-clip on every tick (no drift), and the 1-day snap matches the widget's existing start + 1 day minimum-bar convention. Cancel restoring dates only is fine too, since bar positions derive reactively from dates via timebarStyle.

1. Regression on MainSchedule (blocking). propagateClipToChildren lives in the shared Schedule.vue widget, so it fires for every consumer with editable root bars that have children — and MainSchedule has exactly that shape (production bars with task-type children once expanded). Its onScheduleItemChanged only saves the production: moving a production bar there now visually clips the child bars with no confirmation prompt, no persistence, and everything reverts on reload. Either gate the propagation behind an opt-in prop (e.g. clip-children) that only ProductionSchedule sets, or implement the confirm/save/restore flow in MainSchedule as well.

2. confirmChildMove has no error handling. If one updateScheduleItem(child) rejects mid-loop: unhandled rejection, the modal never closes, pendingParentChange stays dangling, and children are partially saved. Promise.all + a finally to close the modal fixes both the error path and the sequential N calls.

Minor:

• The _dragOrig* stamping block is copy-pasted verbatim in the three moveTimebar* handlers — a small helper would do.
• With isEstimationLinked, cancel restores dates but not the estimation updated during the drag.
• 'sub-item(s)' should use i18n pluralization (key | keys + $t(key, count)), and confirm_move_children isn't inserted at its alphabetical spot in en.js.