Pin the font the layout suite measures, and let the slice say it means plaintext

Two failures left on the runner, with nothing in common except that both only appear on a
machine unlike the one anybody develops on. The runner is Alpine, musl, inside a container,
with no fonts installed at all — and that combination is now reproducible locally, which is
how these were fixed rather than guessed at. Both are verified by running the suite in it.

The layout suite had two causes stacked, and the first hid the second completely. Missing
libfontconfig stops libSkiaSharp loading, which the last commit fixed and which then
revealed the real one: Avalonia takes its default font family from the platform, and on an
image with no fonts there is no answer, so FontManager throws "Default font family name
can't be null or empty" inside AppBuilder.SetupUnsafe — before a single test body runs, for
all sixty-eight of them, naming none of their subjects. WithInterFont does not prevent it:
it registers a collection without nominating a default. HeadlessApp's own comment already
claimed it measured "the same Inter font the application registers", which was an intention
the code never carried out.

Both heads now name it, through FontManagerOptions.DefaultFamilyName. That is worth more
than getting CI green: a suite whose entire job is measuring text was taking its metrics
from whatever the machine happened to have — Segoe UI here, DejaVu there — and reporting
the two as one number. It also means the application uses the font it has been shipping and
declining to use since it first referenced the package; almost nothing moves visually,
because App.axaml already sets MonoFont on essentially everything that draws.

The end-to-end slice was the product being right and the test leaning on an accident.
ServerConnection permits an http authority only when it is loopback. Testcontainers reports
the host a container can actually be reached at, so running the suite directly gives
localhost and passes, while running it inside a container gives the bridge gateway
172.17.0.1 and is refused — correctly, since a client that accepted plaintext metadata from
a routable address would be a weakness for everyone who is not a test. Loosening that rule
was the wrong repair. The slice now passes configureOidc and says out loud that it accepts
plaintext from the Keycloak it started itself.

Verified by reproducing the runner rather than approximating it: dotnet/sdk:10.0-alpine,
musl-x64, fc-list returning zero, the docker socket mounted so Testcontainers resolves the
gateway exactly as it does in CI. The whole solution passes there — 19 suites, 0 failures,
4 skipped — and the end-to-end failure was confirmed causal by reverting only that one file
and watching it fail again in the same container. The layout suite also still passes on a
Fedora desktop with 595 fonts, so the two agree now.

Not verified on Windows, and it should be said plainly rather than left to be discovered:
pinning the family changed the measured metrics there too, so a tight layout assertion
could have moved. platform-flags.md records that, and corrects the entry the last commit
added — "libfontconfig, and nothing else" was true of the container it was tested in and
false of the runner.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/platform-flags.md

@@ -424,13 +424,38 @@ be honest about: the cache offers no protection against another process running
 
 ## Build and CI
 
-**The layout suite needs `libfontconfig` installed, and nothing else.** Avalonia's headless renderer is
-still Skia, and `libSkiaSharp.so` — which the test project copies into its own output — links against
-it. On an image without it, every one of the 69 tests fails inside `HeadlessUnitTestSession` before
-measuring anything, reported as a `TypeInitializationException` on `SkiaSharp.SKImageInfo` that names
-none of the tests' actual subjects. The CI job installs it. Worth being precise that this is the
-library and not fonts: verified in a container where `fc-list` returns zero and the suite passes anyway,
-because the application carries Inter itself.
+**The layout suite needs two unrelated things on a bare image, and each hides the other.** Both were
+found the slow way, one per CI run, because the first masks the second entirely.
+
+The first is `libfontconfig`. Avalonia's headless renderer is Skia, and the `libSkiaSharp.so` the test
+project copies into its own output links against it; without it the native library never loads and all
+69 tests fail inside `HeadlessUnitTestSession` with a `TypeInitializationException` on
+`SkiaSharp.SKImageInfo` naming none of their actual subjects. The CI job installs the package.
+
+The second only becomes visible once the first is fixed, and is not about a package at all. Avalonia
+takes its default font family from the platform, and on an image with no fonts installed there is no
+answer — `FontManager` throws "Default font family name can't be null or empty" during
+`AppBuilder.SetupUnsafe`, again before any test body runs and again for all 69. `WithInterFont` does not
+help by itself: it registers a collection without naming a default. Both `Program.BuildAvaloniaApp` and
+the layout suite's `HeadlessApp` now set `FontManagerOptions.DefaultFamilyName` to
+`avares://Avalonia.Fonts.Inter/Assets#Inter` explicitly, which owes the host nothing because the font
+travels in the package.
+
+Pinning it is worth more than the CI fix. A suite that measures text was taking its metrics from
+whatever the machine happened to have — Segoe UI on Windows, DejaVu on Linux — and reporting both as
+one number. *Verified* on Alpine musl with `fc-list` returning zero and on a Fedora desktop with 595
+fonts, which now agree. **Unverified on Windows:** the pinning changed the metrics there too, so a
+tight assertion could conceivably have moved.
+
+**The end-to-end suite must state its plaintext exemption rather than inherit it.** `ServerConnection`
+allows an `http` OIDC authority only when it is loopback, which is a sound rule the suite cannot lean
+on: Testcontainers reports the host the container is actually reachable at, so running the tests
+directly gives `localhost` and passes, while running them *inside* a container — which is what a
+containerised CI runner does — gives the bridge gateway `172.17.0.1` and is refused. That refusal is
+the product being correct; a client that quietly accepted plaintext metadata from a routable address
+would be a real weakness. `M1VerticalSliceTests` therefore passes `configureOidc` to set
+`RequireHttpsMetadata = false` for the throwaway Keycloak it starts itself, and the rule stays as strict
+as it was for everyone else.
 
 **Integration tests need a Docker daemon** (Testcontainers). They run on `ubuntu-latest` in CI.
 macOS runners have no Docker daemon, and the Windows CI job is deliberately build-only. So