HealthChecks.UI drags EF Core and the whole Roslyn stack into every image, for a dashboard that is off by default

`AspNetCore.HealthChecks.UI` drags 14 assemblies into every published image: the UI packages, Entity Framework Core, and the entire Roslyn stack. Measured in the running 4.1.0 image:

```
HealthChecks.UI.dll, .Client, .Core, .Data, .InMemory.Storage
Microsoft.EntityFrameworkCore.dll, .Abstractions, .Design, .InMemory, .Relational
Microsoft.CodeAnalysis.dll, .CSharp, .Workspaces, .CSharp.Workspaces
19.5 MB uncompressed, 6.8 MB compressed
```

Three things are wrong with that, in increasing order of seriousness.

**Entity Framework Core is in an application that uses Marten.** It is there only as HealthChecks.UI's storage layer, and this deployment uses `HealthChecks.UI.InMemory.Storage`, so no EF provider is doing any work.

**`Microsoft.EntityFrameworkCore.Design 8.0.11` is a design-time package in a runtime image.** It exists for scaffolding and migrations at the command line. It is what pulls `Microsoft.CodeAnalysis.CSharp.Workspaces` and therefore the whole 12.9 MB Roslyn stack. It is also EF 8 inside a .NET 10 application, which nothing here asked for.

**The dashboard is off by default.** All of it ships so that `HealthChecksUI:Enabled` can be switched on, and almost no deployment switches it on.

### It cannot be fixed by deleting the files

Built an image with those assemblies removed and it does not start:

```
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly
'HealthChecks.UI, Version=9.0.0.0, Culture=neutral, PublicKeyToken=null'.
at barakoCMS.Extensions.ServiceCollectionExtensions.AddBarakoCMS(...)
```

The JIT needs the assembly when it loads the method that contains the call, whatever the runtime flag says. So the reference has to go, and the dashboard has to live behind an assembly boundary. That is the same conclusion as #745: an optional feature needs to be a module, not a core reference with a config flag in front of it.

### Also worth knowing: Roslyn is not Marten's

Marten 9 removed runtime code generation entirely. There is no `JasperFx.RuntimeCompiler`, no `codegen write` step, and the `GeneratedCodeMode` options are gone; dispatchers are built by source generators at compile time and Marten 9 is AOT-publishable. So the 12.9 MB of Roslyn in the image belongs to EF Core Design and nothing else, and removing this package reference is also the thing that unblocks ever considering AOT.

### Size, in context

Of the 115.6 MB compressed pull, this chain is 6.8 MB. The base image swap from `aspnet:10.0` to `10.0-noble-chiseled-extra` is 24.2 MB and is a one-line change, measured at 442.7 MiB down to 323.4 MiB on disk with a clean boot. Do that first. This one is worth doing for the dependency hygiene as much as the megabytes.

Start at the AddBarakoCMS(...) entry point shown in the FileNotFoundException and inspect the HealthChecks.UI package reference and startup path. Trace how the disabled dashboard is loaded, then verify a clean published image boots without the EF Core Design and Roslyn assemblies while the optional dashboard remains separately loadable.

Written by the indexing model from the issue text.