The admin UI becomes barakoBrew, the surface where a system is designed and exposed

The admin UI stops being "the admin UI" and becomes **barakoBrew**, the surface where a process owner designs a system and chooses what to expose to the portal (#344).

The name follows work that already happened. Once BaryoDev/barakoCMS#340, BaryoDev/barakoCMS#341 and BaryoDev/barakoBrew#5 land, this surface is not administering a CMS any more, it is designing business objects, deciding who may do what to them, and publishing them to the people who do the work. "Admin UI" describes a settings screen and undersells that.

It also fits the vocabulary already in use: the lean core is `barako-cms-decaf`, the design notes are espresso-first, and the full image is the suite.

## Do it at 4.0, and here is the cost

4.0 is a major and it has not shipped. Renaming after it means either living with the old name until 5.0 or breaking a name inside a major, so this is the cheapest moment there will be.

The only genuinely breaking part is the published image. `ghcr.io/baryodev/barako-admin` has been published since 3.x and sits in people's compose files. Everything else is env-driven or internal: `basePath` comes from `NEXT_BASE_PATH`, and the npm package is called `admin` locally and is not published.

So: publish under the new name and keep pushing `barako-admin` as an alias for the whole of 4.x, pointing at the same manifest. `docker buildx imagetools create` already does this for the Docker Hub mirror, so it is a tag, not a second build. The alias is dropped in 5.0, announced in the 4.0 notes.

## Do not rename the directory yet

`admin/` stays `admin/` for now. Renaming the tree while BaryoDev/barakoCMS#306 and BaryoDev/barakoBrew#5 are both working in it produces conflicts for no user-visible benefit, and nobody outside the repository can see a folder name.

Separating the two is the point: the product name is what people say and pull, and the path is an implementation detail. They do not have to change together and they do not have to change at the same time.

## One thing worth naming out loud

`brew` is Homebrew's command. That is not a code collision, since the CLI in BaryoDev/barakoCMS#345 is `barako` and a subcommand would be `barako brew`, but it is a conversation collision: "run brew" means something else to most developers on a Mac, which is the machine this project is developed on. Worth being deliberate about rather than discovering in a support thread.

The alternative is to keep the surface named for what it does and spend the coffee metaphor elsewhere. Recorded so the choice is made rather than defaulted into.

## Done when

- The surface calls itself barakoBrew in its own UI, its README, the docs and the site.
- `ghcr.io/baryodev/barako-brew` is published, and `barako-admin` still resolves for the whole of 4.x.
- The 4.0 release notes say the old name is an alias and when it goes.
- `admin/` is untouched.

Related: BaryoDev/barakoBrew#4, which this surface configures, and BaryoDev/barakoCMS#306, which is already changing this UI for the 4.0 contract.