feat(mudblazor): announce required fields without the HTML5 required attribute (#263)

[phmatray]

Implements #263.

Closes #263.

Executing the implementation plan task-by-task; the checklist below — and the plan on the issue — are
ticked as each task lands. Opened as a draft — will be marked ready after the final task and a
code-review pass.

Plan

• Task 1: Open the upstream MudBlazor PR
• Task 2: Raise the MudBlazor pin
• Task 3: Flip both render paths to the ARIA-only mechanism
• Task 4: Restore the convention wording and document

---

What shipped

Mechanism	.Required(...) now contributes aria-required="true" through UserAttributes; MudBlazor's Required parameter is reserved for the explicit .WithNativeRequired() opt-in
Pin	MudBlazor 9.8.0 → 9.9.0, which carries MudBlazor#13613 — contributed from this repo
Coverage	text, numeric, date, select, multi-select, autocomplete, lookup, LOV and boolean
Tests	1,634 pass across all three suites (883 + 588 + 163), 0 fail, 1 pre-existing skip

Verified rather than assumed:

• The version floor is real. Reverting the pin to 9.8.0 turns 9 of 35 AriaRequiredTests red. The mechanism genuinely depends on the upstream fix, so Directory.Packages.props must not drop below 9.9.0.
• The guard bites. Deleting the aria-required splat from one component turns 5 tests red.
• ./build.sh Format (the CI gate) clean; dotnet build -c Release 0 warnings under TreatWarningsAsErrors.

The asterisk — a deliberate trade, not an oversight

MudBlazor draws its * from the same Required parameter as the HTML5 attribute, and #13613 separated only the ARIA write. So dropping the attribute drops the asterisk with it; they cannot be had separately. The spec chose that over inventing a FormCraft-owned marker, keeping .WithNativeRequired() as the way back. Pinned by Required_Field_Should_No_Longer_Carry_MudBlazors_Visible_Marker and Explicit_Native_Required_Should_Restore_The_Marker_And_The_Html5_Attribute, read as a pair.

Deviations from the plan

• "Both render paths" is now one. The plan predates Converge the two render paths: collection item fields duplicate the field renderers instead of using them #203, which deleted the imperative RenderTreeBuilder path; item fields render through the same components as ordinary ones. CollectionFieldComponent.AddCommonFieldAttributes/RenderBooleanField, named in the plan's key files, no longer exist. The parity tests still compare the two placements and were updated.
• WithNativeRequired's XML doc lives in core, not FormCraft.ForMudBlazor/Extensions/ as the plan says — Move the UI-agnostic adapter machinery into FormCraft core #279 moved it.
• Booleans needed the split too. The spec's edge case said checkboxes "need no change" because they already use the UserAttributes route. True for the ARIA half, but MudCheckBox writes required from Required at sequence 24, after its splat (decompiled from 9.9.0), so a required checkbox still carried the HTML5 attribute. It gets the same split.
• Task 1's step 3 says to cite MudBlazor's AGENTS.md. The upstream PR deliberately does not — that citation was removed at the author's request before the PR was filed.

Follow-ups

• File upload still shows an asterisk when other field types no longer do. MudBlazorFileUploadComponentBase marks the requirement in its own <MudText> label plus an aria-describedby hint (Mark required file-upload fields — the one field type #199 left unannounced #262) rather than through MudBlazor's Required, so it was untouched here — correctly, since the spec lists it as a non-goal. The result is a visible inconsistency: a required upload is marked, a required text field is not. Worth deciding deliberately, either way.
• The FluentUI adapter still couples the two. FluentUIFieldComponentBase.EffectiveNativeRequired keeps the full resolve and drives Required on Fluent inputs. Whether Fluent has the same HTML5-attribute concern is unmeasured; Drop the HTML5 required attribute once MudBlazor honours caller-supplied aria-required #263 was scoped to MudBlazor.
• .worktrees/ is not in .gitignore. .claude/worktrees/ is (since chore: restore the newline that merged two .gitignore entries into one #223), but the kit's other default home is not, so a worktree planted there would be stageable by git add -A. One line would settle it; not added here, since it is unrelated to this change.