Asset compiler: load from .sdbuild manifests instead of walking the csproj graph

[xen2]

PR Details

The asset compiler used to rediscover which assemblies and assets to load by re-walking the csproj/ProjectReference graph on every run and guessing from implicit conventions.

Now every project emits a small .sdbuild manifest at build time (into obj/) describing exactly what the compiler needs (package, asset items, assemblies, referenced manifests, lock file) and the compiler reads that instead of evaluating MSBuild.

NuGet packages declare their asset types in their packed sdpkg.

Highlights

• ~9× faster in-tree asset compile, ~40% for consumers (Stride.Graphics.Tests ~14.5s → ~1.6s; a consumer game ~4.1s → ~2.4s). Evaluation moves into the build, where it's incremental.
• Unambiguous semantics — a missing assembly is now always a real error, not "broken or just unnecessary?". No first-TFM-ordering accident, no loading unrelated graph assemblies.
• One declaration in csproj, <StrideAssetAssembly> which means "this assembly's types appear in assets", the single authoring surface. On by default for game/code projects; the generation and pack targets both consume it.
• Mobile/cross-platform builds no longer fragile: non-host TFMs reference their host-TFM sibling manifest; no path guessing, no on-demand graphics-API build. Validated on Android.
• New analyzer STRDIAG011 warns at compile time when an IProjectAsset type's extension isn't declared, instead of silently dropping its assets. ≤5 ms/compilation.
• CI — tests/enduser/Stride.Packaging.Tests (Windows + Linux) packs a real plugin and consumes it via a true PackageReference.

What this unlocks

• First-class third-party asset plugins over NuGet: a package ships asset types and they load because it declares them (AssetAssemblies), proven load-bearing by the packaging test. Previously only worked by accident for engine packages the compiler force-registers.
• Plugins can add their own project-source asset extensions; the extension list is now a transitive, plugin-extensible property (+ the analyzer guard) rather than a hardcoded engine edit.
• Sub-process / isolated asset builds with no live csproj graph required, CI suites no longer each re-evaluate the engine project graph.
• Foundation for editor plugin surfaces and metadata-only editor loading. sdpkg is now the declared place a package describes its surface.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.

[xen2]

/ci e2e

[stride-chatops]

@xen2 — /ci dispatched:

• editor: https://github.com/stride3d/stride/actions/runs/27538061922
• samples: https://github.com/stride3d/stride/actions/runs/27538069597

⚠️ This PR modifies workflow YAML used by /ci, but the bot runs master's version:

• .github/workflows/test-windows-editor.yml

Land workflow changes on master first if you need them tested.

[stride-chatops]

@xen2 — /ci complete (some failed):

• ❌ editor: https://github.com/stride3d/stride/actions/runs/27538061922
• ❌ samples: https://github.com/stride3d/stride/actions/runs/27538069597

[VaclavElias]

I wonder if your updates allow using this feature https://learn.microsoft.com/en-us/dotnet/core/sdk/file-based-apps for some small examples.

I tried most recent stride build a few days ago with our community toolkit but obviously it doesn't work because the project is created somewhere in the temp folder and the asset compiler paths are not aware of such scenario. I can create a separate issue for that but maybe this is really low priorirty.

[xen2]

/ci e2e

[stride-chatops]

@xen2 — /ci dispatched:

• editor: https://github.com/stride3d/stride/actions/runs/27602178137
• samples: https://github.com/stride3d/stride/actions/runs/27602183349

⚠️ This PR modifies workflow YAML used by /ci, but the bot runs master's version:

• .github/workflows/test-windows-editor.yml

Land workflow changes on master first if you need them tested.

[stride-chatops]

@xen2 — /ci complete (some failed):

• ✅ editor: https://github.com/stride3d/stride/actions/runs/27602178137
• ❌ samples: https://github.com/stride3d/stride/actions/runs/27602183349

[Kryptos-FR]

I wonder if your updates allow using this feature https://learn.microsoft.com/en-us/dotnet/core/sdk/file-based-apps for some small examples.

I tried most recent stride build a few days ago with our community toolkit but obviously it doesn't work because the project is created somewhere in the temp folder and the asset compiler paths are not aware of such scenario. I can create a separate issue for that but maybe this is really low priorirty.

I also think it is low priority but it's nice to track it as an issue.