No .NET client, so a MAUI or Blazor consumer writes their own

**Blocked by #181, #182, #183.** Do not start before those land: the shape of this is decided by them.

## Why

There is no .NET client for barakoCMS. `BarakoCMS` on NuGet is the server.

That means a MAUI or Blazor starter would contain a hand-rolled `HttpClient` wrapper, and that wrapper becomes the thing everyone copies. Three incompatible half-clients with no owner is a worse outcome than no starter at all.

## What it is

The same shape as the TypeScript client from #182: a hand-written base plus generated slices, from the same OpenAPI document and the same generator chosen in #183.

The base carries transport, authentication, the token store, refresh, the tenant header and one error shape. Slices carry the typed method surface, one per tag.

## Consumers, in order of likelihood

| consumer | needs |
|---|---|
| Blazor | the whole thing, and it is the closest to the existing admin UI in shape |
| MAUI | the whole thing, plus attention to token storage on device |
| workers, console tools, integrations | mostly content read and write |

## What is not obvious

**Token storage differs by host.** A browser, a MAUI app and a background worker want different things, and the base client should take a storage abstraction rather than assume one. Getting this wrong means either insecure storage on device or a client that cannot run headless.

**Cancellation and `HttpClient` lifetime.** A .NET consumer will expect `CancellationToken` on everything and will expect to supply their own `HttpClient` or `IHttpClientFactory`. A generated client that news up its own is unusable in ASP.NET.

## Publishing

Needs a NuGet Trusted Publishing policy for the new package id, which only the account owner can create. Flag it before the first release rather than at the end.

Design: `docs/2026-08-18-client-layer-design.md`.