Fix part rename not persisting for potential excerpts

[manolo]

Resolves: #31656

When renaming a part in the Parts dialog, the new name wasn't persisted to the .mscz file unless the part had been opened as a tab first.

Root cause: "Potential" excerpts shown in the Parts dialog are not in masterScore()->excerpts() until explicitly created. Since mscsaver only saves excerpts in the master's list, renaming a potential excerpt had no effect.

Solution: ChangeExcerptTitle now checks if the excerpt is in the master's list before renaming. If not, it calls initAndAddExcerpt() to add it, ensuring it gets saved.

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it resolves
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)

[cbjeukendrup]

This is not ideal, because initialising an excerpt is an expensive operation, and it is wasteful to populate and store the entire excerptScore while we only really need to store the excerpt's name.

Instead, the solution to this and some other issues, should be to move the concept of "potential excerpts" to the engraving/dom level, instead of having it at the MasterNotation/PartListModel level.
Potential excerpts should just be Excerpt but with no Score yet. Such excerpts should be created for each instrument when the master score is initially created, and when new instruments are added.
They should be stored in the MSCZ file, even if no properties have been modified compared to the defaults. However, the file format for potential excerpts might need to be slightly different because of the absence of a Score. It should only store a name and a list of Parts.

This is a somewhat big refactor, but I think it's worth it. It would also result in the ability to delete potential excerpts without having them appear back next time you open the parts dialog, and it would make it easier to fix the problems with the reset functionality.

Let us know if you're happy to look into this!

[manolo]

@cbjeukendrup,

Is it acceptable if older MS versions simply ignore or skip lightweight excerpts? The excerpt would be auto-regenerated from parts, losing only the custom name.

If yes, what is the preferred approach?

• Store lightweight excerpt data somewhere else, not in Excerpts/*.mscx, so older versions do not see it
• Write a minimal valid XML that older versions can parse but then discard as empty or invalid

The current PR approach uses full excerpts and is always backward compatible, but produces bigger files when part is not yet needed.

Another option would be a breaking change. Older versions would fail to open files with lightweight excerpts, which means refusing to open any 4.7+ file.

[manolo]

Write a minimal valid XML that older versions can parse but then discard as empty or invalid

I investigated a little bit this approach, and it appears it's not feasible. From what I can see, older MS versions process each file in Excerpts/*.mscx as follows:

1. readScoreFile() parses the XML expecting a full Score structure
2. If parsing fails → break → it seems the entire file load fails (not graceful)
3. Even if we write a minimal parseable Score, subsequent operations like linkMeasures() and addExcerpt() apparently assume a fully populated score and would likely crash on an empty one

It looks like the old code doesn't have a "discard invalid excerpt" path - it either succeeds completely or fails the entire file load.

[cbjeukendrup]

We are prohibiting opening 4.7 files in older versions (like we did with all 4.x releases), so we don't need to worry about backwards compatibility. (Officially, that's not entirely in line with the SemVer philosophy, but we have decided to allow ourselves to do this anyway because MuseScore is still so much under development.)

[manolo]

@cbjeukendrup I have a branch with the approach you described. Is it better to close this PR and open a new one from a clean master, or do you prefer that I revert the commits here and continue the discussion and review in this PR?

[cbjeukendrup]

A new fresh PR would be great! (UX on GitHub doesn't really improve when threads become longer...)

[manolo]

Closing this PR to continue with the suggested implementation in #31738