Preserve ItemGroup evaluation order in template manifest normalization #20629

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Non-blocking follow-up to this review comment on #20574.

TemplateRestorePlan.Normalize in tools/GenerateTemplateManifest/TemplateRestorePlan.cs sorts unconditional ItemGroup children to canonicalize restore graphs. These rendered projects have not yet been evaluated by MSBuild, so sorting can change the meaning of order-sensitive item expressions.

For example:

<ItemGroup>
  <TemplatePackage Include="System.CommandLine" Version="2.0.12" />
  <PackageReference Include="@(TemplatePackage)" />
</ItemGroup>

Sorting moves PackageReference before TemplatePackage. The reviewer reports that an MSBuild/restore probe restored System.CommandLine/2.0.12 from the original project, while the normalized project restored successfully with no libraries or dependencies. The resulting manifest would silently omit the package.

No current template uses an @(...) item expression, so this is not evidence that the current manifest is incomplete. This issue should not block #20574.

Expected Behavior

Normalization should preserve ItemGroup document order, including order across combined groups, so evaluating the generated project selects the same dependencies as evaluating the original.

Prefer preserving item order rather than attempting to recognize every order-sensitive expression. Possible approaches include canonicalizing only safe PropertyGroup shapes, or combining item groups without sorting their children.

Add an MSBuild-evaluation/restore regression test that proves the package in the example remains present after normalization. Confirm that existing template graph deduplication and manifest output remain correct.

Steps To Reproduce

1. Create a minimal SDK-style project targeting a supported framework and containing the ItemGroup above.
2. Evaluate/restore the original project and record its package references and project.assets.json libraries.
3. Pass the project XML through TemplateRestorePlan.Normalize, save the normalized project in an isolated directory, and evaluate/restore it.
4. Compare the results. As reported in the linked review, sorting places the item consumer before its declaration, omitting System.CommandLine without causing restore to fail.

Exceptions (if any)

None reported: restore succeeds with the dependency missing.

Aspire doctor output

N/A — build-time template manifest normalization.

Anything else?

The reviewer also reports that removing ItemGroup sorting did not change the current plan size: 138 configurations / 518 project instances → 78 unique projects / 105 framework graphs. Recheck this when implementing the fix; preserving order may have no deduplication cost for today's templates.

Related: #20451. The existing guard against moving groups across top-level Choose/Import/Target elements addresses a different evaluation-order issue; this follow-up concerns sorting the item declarations themselves.