refactor(core)!: share diagnostics warning log and per-form latch across adapters (#398)

[phmatray]

Implements #398.

Closes #398.

Executing the implementation plan task-by-task; the checklist below — and the plan on the issue — are
ticked as each task lands.

Plan

• Task 1: Move DiagnosticLog and the per-form latch into core
• Task 2: Route FluentUI's custom-template warning through the moved types

Review (Standards / Spec / Verification, run per implement-issue Step 7)

Standards — one real finding: a stale doc comment in
FormCraft.ForFluentUI.UnitTests/Components/CustomTemplateTests.cs claiming the adapter has "no
shared diagnostics infrastructure" (now false, since this PR gives it one) and naming the renamed
DiagnosticLog type. Fixed.

Spec — flagged that FormCraftComponent.razor.cs (FluentUI) now emits its custom-template
warning under a new fixed category, "FormCraft.ForFluentUI.CustomTemplateField", in place of the
prior per-TModel ILogger<FormCraftComponent<TModel>>>() category, and read the issue's Spec text
("FluentUI... keeps its own... category string for the unresolved-custom-template-field diagnostic")
as forbidding that. Verdict: disagree, kept as implemented. The issue's own Implementation
Plan (Task 2, Step 3) explicitly directs adding this exact constant, "matching MudBlazor's call
shape exactly" — MudBlazor's identical diagnostic already uses a named category
(FormCraft.ForMudBlazor.CustomTemplateField), so FluentUI's prior per-TModel category was itself
the inconsistency this issue exists to remove, not a fact to preserve. The Spec text's assumption
that FluentUI "already has" a dedicated category string doesn't match the pre-PR code. Also flagged
(and independently found by the Verification pass): the issue's acceptance criterion 4's grep
pattern was already non-clean before this PR touched anything, because of the unrelated, pre-existing
SecurityEnforcer (#321/#402) logger resolution at the same file — the criterion's grep is
over-broad, not something this PR's diff could ever satisfy literally.

Verification — one real gap: the new category string had no test asserting its value (only
message text was checked). Fixed — CustomTemplateTests.cs's local CapturingLoggerProvider now
tracks category like the core one does, and the regression test asserts
entries[0].Category.ShouldBe("FormCraft.ForFluentUI.CustomTemplateField"). Also caught: an
Entries property on FormCraft.ForMudBlazor.UnitTests/TestSupport/CapturingLoggerProvider.cs left
with zero callers once DiagnosticLogTests moved to core — removed.

Notes for the owner

• Source-compat break, by design of the issue. FormDiagnosticScope was public in
  FormCraft.ForMudBlazor (cascaded as a public parameter on MudBlazorFieldComponentBase), not
  internal as the issue's Spec assumed. Moving it to FormCraft.Diagnostics without a forwarding
  shim (per the issue's own explicit instruction — "not kept as a compatibility forwarder") is a
  source break for any third-party code that referenced FormCraft.ForMudBlazor.FormDiagnosticScope
  directly. This is a preview series (3.1.1-preview.*) and the demo apps build clean, but the PR
  title (refactor(core): ...) won't flag this to release-please the way a ! would. Flagging here
  for a call on whether to add one.

Fixed along the way

• Stale doc comment (Standards finding above).
• Verification gap: category assertion on FluentUI's custom-template diagnostic (Verification finding above).
• Dead Entries property on FormCraft.ForMudBlazor.UnitTests's CapturingLoggerProvider, orphaned by moving DiagnosticLogTests to core.

Follow-ups

• Three near-identical CapturingLoggerProvider test doubles now exist (MudBlazor's shared
  TestSupport one, FluentUI's local one, and core's new DiagnosticTestDoubles.cs), each justified
  as "one file's/project's worth of use." Consolidating them into one shared test-support package is
  out of scope for this issue (FluentUI hand-rolls its own diagnostics warning latch instead of sharing MudBlazor's DiagnosticLog #398 only moves production diagnostics code) but is the same
  duplication shape Diagnostic emission is copy-pasted four times across the MudBlazor package #284/Diagnostic test-support helpers are still duplicated per suite #305 already named once; worth a dedicated issue if a fourth copy appears.

BREAKING CHANGE: FormDiagnosticScope and DiagnosticLog move from FormCraft.ForMudBlazor to FormCraft.Diagnostics (core). Code that references them by the old namespace must update its using directive. No forwarding shim is provided.

BEGIN_COMMIT_OVERRIDE
refactor(core)!: share diagnostics warning log and per-form latch across adapters (#398)

BREAKING CHANGE: FormDiagnosticScope and DiagnosticLog moved from FormCraft.ForMudBlazor to FormCraft.Diagnostics (core). Code that references them by the old namespace must update its using directive. No forwarding shim is provided.
END_COMMIT_OVERRIDE