Pick and pin a client generator, and prove one slice end to end

**Foundation.** Blocked by #181.

## Do not write a generator

Maintaining code-generation templates for TypeScript and C# is a project in itself, and the kind that quietly becomes the main thing you work on. What ships is a **configured invocation of an existing generator**: a command, a pinned version, and a config file.

Candidates, to be evaluated against the actual document rather than on reputation:

| generator | covers | note |
|---|---|---|
| Microsoft Kiota | C#, TypeScript, and more | one tool for both targets, which is the main attraction |
| NSwag | C#, TypeScript | .NET native, long-standing |
| openapi-generator | everything | Java toolchain, largest template library |

## What "evaluated" means here

Not a feature comparison. Generate the same document with each and answer:

- **Does it produce one type per tag**, so `client.content.*` and `client.accounting.*` exist as groups? This is the whole reason #181 comes first.
- **Is the output committable?** It gets published, so it has to be readable enough to review in a diff.
- **Can the transport be swapped**, so generated slices sit on top of the hand-written base from the base-client issue rather than bringing their own HTTP stack and auth?

That last one decides it. A generator that insists on owning the HTTP client cannot be layered under a base that already handles auth, refresh and tenancy.

## Pin it

Once a generator is chosen, its version and configuration are as much a public contract as the API: the shape it emits is what people compile against. Pin the version, commit the config, and treat a generator upgrade as a client release with its own review.

## Deliverable

One slice, generated end to end, reviewed as output rather than as code someone wrote. Not the full client.

## Blocks

The base client split, `barako client generate` in #169, `BarakoCMS.Client`, and CI regeneration.

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