Fix .NET 10 source app detection (TargetFramework regex)

[rkoster]

Problem

Deploying a source-based app targeting net10.0 fails during staging at the "Finalizing Dotnet Core" step with:

**ERROR** Unable to install dotnet-runtime: could not find a version of dotnet-runtime to install

This happens even though dotnet-sdk/dotnet-runtime/dotnet-aspnetcore 10.0.x are already vendored in manifest.yml (added in #1175 and follow-up dependency-bot commits).

Root cause

The TargetFramework regex in src/dotnetcore/project/project.go (SourceInstallDotnetRuntime) only matched a single digit major version:

targetFrameworkRE := regexp.MustCompile(`net(?:coreapp)?(\d\.\d)(?:\w+)?`)

This matches net8.0/net9.0 fine, but never matches net10.0, so runtime version detection fails for any two-digit major.

Fix

• Widen the major-version capture group from \d to \d+.
• Add a unit test case (net10.0, mirroring the existing net5.0/netcoreapp6.7 cases) in project_test.go.
• Add a source_10.0 fixture (net10.0 MVC app, mirroring source_9.0) and a with .NET Core 10 switchblade integration spec in default_test.go asserting a successful source-based deployment.

Dependency version bumps (also fixed here)

Fixing the regex alone wasn't enough — it uncovered two further, unrelated issues that had to be fixed for .NET 10 to actually be usable:

1. SDK/runtime version mismatch. The vendored dotnet-sdk 10.0.300's own CLI tooling requires Microsoft.NETCore.App >= 10.0.8 just to run, but manifest.yml only vendored dotnet-runtime/dotnet-aspnetcore 10.0.2 — and the .NET host can roll a runtime forward to a newer patch, never backward. So even with the regex fixed, staging still failed later at dotnet publish with You must install or update .NET to run this application. Fixed by bumping to the matching 10.0.10 (merging already-mirrored dependency-bot PRs #1305/#1303).

2. cgroup v2 root-cgroup segfault (upstream runtime bug). .NET 10.0.10 is exposed to dotnet/runtime#130092 — a regression introduced in .NET 9.0 (dotnet/runtime#93611) where, when a process's cgroup path is the root of the cgroup v2 mount (no per-container subdirectory nesting — seen in practice on some Diego cells), the hierarchical memory-limit walk-up loop reads past the mount root, causing an access violation crash during app startup. This is independent of the DOTNET_GCHeapHardLimit work in #1317 — it's an outright segfault during early CLR/GC init, before any GC config is consulted. Fixed upstream in dotnet/runtime#130377, backported to release/10.0 via dotnet/runtime#130404, and shipped in .NET 10.0.11 (released 2026-08-11, confirmed via the dotnet/core release manifest). This PR now bumps dotnet-runtime/dotnet-aspnetcore to 10.0.11 and dotnet-sdk to 10.0.400 accordingly (merging already-mirrored dependency-bot branches, each independently verified: artifact URLs return HTTP 200 and downloaded artifacts' SHA256 matches the manifest).

Verification

• go build/go vet clean.
• Full unit suite passes (project, finalize, hooks, supply).
• New unit test verified RED (failed for the expected reason) before the regex fix, GREEN after.
• New integration spec verified live against the docker switchblade backend end-to-end: SDK install → runtime/aspnetcore install → dotnet publish succeeds → app serves the expected homepage content.
• Verified live on a real CF foundation (not just Docker/switchblade): deployed a net10.0 source app using a locally-built cached buildpack zip from this exact branch state — staging succeeded (SDK 10.0.400 → runtime 10.0.11 → aspnetcore 10.0.11 → dotnet publish), app started and served HTTP 200 on first request.

[rkoster]

Addressed review feedback (via Slack) that the newly-added `dotnet-runtime`/`dotnet-aspnetcore` 10.0.11 and `dotnet-sdk` 10.0.400 manifest entries had an empty `source_sha256` field. That field records the sha256 of the original `builds.dotnet.microsoft.com` artifact (distinct from `uri`/`sha256`, which point at the already-verified `buildpacks.cloudfoundry.org` mirror).

Downloaded each of the three original Microsoft-hosted artifacts directly and filled in their sha256:

• aspnetcore-runtime-10.0.11-linux-x64.tar.gz: d3504b4b7c1898b668f58ab0ea4d28821a520a97c9a758b8bb68a424a6f1ccef
• dotnet-runtime-10.0.11-linux-x64.tar.gz: 7d847ecaa123efae40b114c5d45641e456b4cd65e5114b4612095d45d7c71a63
• dotnet-sdk-10.0.400-linux-x64.tar.gz: 7ad9d2db01512e41fd580a0630321bb70cd062d7fe4c5badfb4ce81ec1eddbb8

(71b2e6b)

[tnikolova82]

lgtm

[wayneeseguin]

@rkoster Also, LGTM