Add solution graph semantic target-matrix tests

### Problem

Solution graph changes can preserve successful CI results while silently changing which projects or solution hooks execute. Recent work on synthetic solution graph nodes exposed gaps where default/`Build` behavior was covered, but `Clean`, `Rebuild`, `Publish`, `Pack`, custom targets, platform mappings, and target-ordering semantics were not validated end to end.

Contributors currently need detailed knowledge of graph topology and target propagation to identify these regressions during review.

### Proposal

Add an end-to-end differential test harness that builds the same generated solution normally and with static graph mode, records structured execution markers, and compares normalized results.

Cover:

- default target and `Build`
- `Clean`, `Rebuild`, `Publish`, and `Pack`
- custom targets
- project-qualified targets such as `Project1:Clean`
- solution-level `BeforeTargets`, `AfterTargets`, and `DependsOnTargets`
- differing solution/project configuration and platform mappings
- multi-project solutions and project references

Each project and solution hook should record `(project, target, configuration, platform)` markers. Compare the execution set between standard and graph builds, with explicit ordering assertions where ordering is contractual.

### CI integration

Run the tests in the existing `Build.UnitTests` suite. Consider exposing the matrix as a separately named, fast PR check so failures clearly identify solution graph semantic regressions.

### Exit criteria

- The target matrix runs automatically in PR validation.
- Missing project target execution fails with a clear expected-versus-actual diagnostic.
- Solution hook and target-ordering behavior is covered.
- Configuration/platform mapping regressions are detected.