Page lock retains a missing measure reference after expanding multimeasure rests

Issue type

UX/Interaction bug (incorrect behaviour)

Description with steps to reproduce

Expanding multimeasure rests can leave a page lock referencing a generated measure that is no longer present in the saved score.

1. Download and extract the score ZIP, then open repro.mscz (15 empty measures compressed into a multimeasure rest, with the current page layout locked).
2. Open Format > Style > Rests.
3. Uncheck Multimeasure rests, then click OK.
4. Save the score.

Actual: the affected page lock remains. In the saved MSCX, its endMeasure refers to EID 9oIdnbJLpXJ_4BKqCbAdIvH, but no element in that file has that EID anymore.

Expected: remove the affected page lock when the multimeasure rest expands, as intended by the existing removePageLocksContainingMMRests style-change cleanup.

The score's visual layout alone is not a reliable indicator of this defect. The recordings show the GUI operation; the supplied saved files and endpoint inspection demonstrate the difference.

Supporting files, videos and screenshots

Before fix: 20-second desktop recording:

https://github.com/user-attachments/assets/b0d83f5c-c57b-43e1-bb3b-97425f6f7cbb

After candidate fix: equivalent 20-second recording:

https://github.com/user-attachments/assets/b290298c-039e-46b5-b949-2609039b1938

• Scores: reproduction input and saved before/after, undo/redo and reopened states
• Evidence details and preparation steps; Python saved-file inspection script

Saved state	Multimeasure rests enabled	Page locks	Missing endpoint EIDs
Input	Yes	1	0
Before fix, expanded	No	1	1
After fix, expanded	No	0	0
After fix, undo expansion	Yes	1	0
After fix, redo expansion	No	0	0
After fix, reopen and Save As	No	0	0

The input was prepared through desktop commands from the existing src/engraving/tests/page_locks_data/page_locks-1.mscx fixture, also included in the ZIP. Evidence files are hosted in a separate branch of my fork.

In which versions of MuseScore Studio is this issue present?

Development main ce7067126406142e51eb7772b11fac239a1dc873, built from source. Framework submodule: ee2c97edf5fff6ae46289851ec8e2968a5deb045.

Regression

I was unable to check the release-version boundary.

Operating system

Ubuntu 24.04.2 LTS, Qt 6.10.2/GCC 14, native APP Debug build with ASan. Desktop operations were agent-operated through Xvfb/xdotool.

Additional context

The cleanup scans ordinary measures using mmRest(), but a lock endpoint can itself be a generated MMRest (isMMRest()). A candidate correction checks generated endpoints before the existing traversal.

The original five native page-lock tests pass on unchanged source; an additional probe fails because the old lock is retained. With endpoint cleanup, all six pass. The candidate was also built and tested on official main, with an explicit generated-endpoint precondition.

Related work: #33737 introduced page locks; #34505 fixes frame-ending locks and is distinct. #27473 establishes removal behavior for affected system locks when multimeasure rests expand. Searches found no exact duplicate or active matching fix, but this is not a claim of first discovery.

This report and candidate contribution were prepared with AI assistance.

Checklist

• This report follows the bug-reporting guidelines.
• I searched the issue tracker for similar reports; related work is listed above.
• All requested files and information are supplied through the evidence links above.
• I attempted to identify the root problem concisely and supplied a small reproducible score.