Undoing a data source or code generator delete restores it at the end, reordering the schema

[matt-edmondson]

Problem

Undoing a delete puts the element back at the end of its collection rather than where it was, because Schema.RestoreDataSource and Schema.RestoreCodeGenerator append. Delete a data source from the middle of the list, undo, and the schema comes back reordered — and that reordering is written to the .schema.json on the next save, so an undone edit still produces a file diff.

Found while writing the editor tests in #140.

Why it is not already fixed

#140 fixed the same bug for members, classes and enums, by remembering the index before the delete and moving the element back to it on undo:

int index = schema.ClassSet.IndexOf(captured);
// ...
() =>
{
    schema.RestoreClass(captured);
    schema.ClassSet.Move(captured, index);
}

That works because Schema exposes an ordered set for those two:

public SchemaChildSet<SchemaClass, ClassName> ClassSet => new(ClassesInternal);
public SchemaChildSet<SchemaEnum, EnumName> EnumSet => new(EnumsInternal);

There is no equivalent for data sources or code generators — only IReadOnlyCollection<T>, which has neither IndexOf nor Move. So the editor has nothing to reposition them with, and the fix could not be applied without adding public API to a published package. That is a decision for the project owner rather than something to slip into a test PR.

Scope

Add the two missing accessors, mirroring the two that exist:

public SchemaChildSet<DataSource, DataSourceName> DataSourceSet => new(DataSourcesInternal);
public SchemaChildSet<SchemaCodeGenerator, CodeGeneratorName> CodeGeneratorSet => new(CodeGeneratorsInternal);

Then apply the same index-preserving restore to the two delete commands in SchemaEditor/TreeDataSource.cs and SchemaEditor/TreeCodeGenerator.cs.

The addition is additive and non-breaking. The asymmetry looks accidental rather than deliberate — it is not obvious why classes and enums have an ordered accessor and the other two children of Schema do not.

Alternative

If the ordered accessors are deliberately withheld, the other option is to make RestoreDataSource / RestoreCodeGenerator (and arguably RestoreClass / RestoreEnum / RestoreMember) take the index to restore at. Their doc comments already say they exist "for undo operations where the original object reference is preserved", so restoring at the end is arguably wrong in the library rather than in the editor. That is the larger change of the two, but it fixes the bug for every caller rather than every caller having to know to repair the order afterwards.

Acceptance criteria

• Deleting a data source and undoing restores it at its original position.
• Deleting a code generator and undoing restores it at its original position.
• Both are covered by tests in SchemaEditor.Test, alongside the existing ones for classes, enums and members.