Pin SDK to the 10.0.3xx feature band

[gunndabad]

Context

Every Tests (SupportUi.EndToEndTests) run on CI has failed since 2026-08-11 20:40. It looks like flakiness — 13 of 142 tests fail, the rest pass — but the split is deterministic: the failures are exactly the tests that touch an accessible-autocomplete field (all 6 in AddRouteToProfessionalStatusTests, the 5 autocomplete ones in EditRouteToProfessionalStatusTests, plus AddMq and EditMqProvider).

global.json pinned "version": "10", which floats to any 10.x SDK, so CI started using SDK 10.0.400 the day it was released (2026-08-11) — exactly when the failures began.

Root cause (upstream): on 10.0.400, only the first tag-helper element inside a @section block is bound. Every subsequent element in that section is emitted as literal markup, so ~/ is never resolved. The build succeeds with no warning.

In SupportUi/Pages/Shared/_Layout.cshtml, @section Head opens with <meta name="htmx-config" …> — that one binds, and everything after it does not:

SDK	Generated	Rendered
10.0.301 / 10.0.303	CreateTagHelper<UrlResolutionTagHelper>()	<link href="/app.657ritalq7.css">
10.0.400	WriteLiteral("~/app.css")	<link href="~/app.css">

The browser resolves the literal ~/… relative to the current page, so /routes/add/~/Components/accessible-autocomplete.min.js 404s, accessibleAutocomplete is undefined, the page's window.onload handler throws, and the <select> is never enhanced into input#{id} — which is what the tests wait for.

Upstream tracking: dotnet/razor#13216, #13217, #13218 — all closed as fixed by dotnet/roslyn#84771, backported to the 10.0.4xx band in dotnet/roslyn#84782. The fix has not shipped yet — 10.0.400 is still the only 10.0.4xx SDK released.

Changes proposed in this pull request

Pin global.json to the 10.0.3xx feature band:

{ "sdk": { "version": "10.0.300", "rollForward": "latestPatch" } }

10.0.303 shipped the same day as 10.0.400 on the same 10.0.11 runtime, so this costs nothing but the SDK feature band — we stay on the current runtime and keep getting patch updates within 10.0.3xx.

Since the upstream fix is already merged and backported, this pin should be short-lived: drop it once a 10.0.4xx containing roslyn#84782 is released.

Guidance to review

Exact blast radius. I built both web projects under 10.0.400 with EmitCompilerGeneratedFiles and grepped the generated code. Affected: 5 URLs, all in SupportUi/Pages/Shared/_Layout.cshtml (app.css, both accessible-autocomplete.min.*, moj-frontend-9.0.0.min.css, htmx.min.js). AuthorizeAccess is not affected — in both of its @section blocks the ~/ element happens to be the first tag helper, so it still binds. No asp-* attributes leak anywhere in either project.

This is a production bug, not just a test bug. SupportUi built with 10.0.400 serves a page with no CSS and no working JS. We're only safe today because the Dockerfile pins the SDK image by digest (unchanged since June, so still 10.0.3xx). When dependabot next bumps that digest past 10.0.400, the build would have silently shipped broken assets — with this pin it fails loudly at build time instead.

Narrower fixes were tried and rejected:

• Adding asp-append-version="true" to force a tag-helper binding — no effect, because the element still isn't the first tag helper in the section. This is what ruled out a per-element workaround.
• Rewriting ~/ to / — works, but loses static-asset fingerprinting, and would need re-checking against every future SDK.

Verification

• Reproduced locally by installing SDK 10.0.400 — the same 6 AddRouteToProfessionalStatusTests failed with the identical Playwright errors seen on CI.
• Confirmed SDK 10.0.303 renders the URLs correctly, and that the pin rejects 10.0.400.
• just build — 0 errors.
• All 142 SupportUi.EndToEndTests pass.
• just format-changed — no changes.

Checklist

• Attach to Trello card
• Rebased master
• Cleaned commit history
• Tested by running locally

🤖 Generated with Claude Code