makeover-tui 0.1.0

The terminal renderer for makeover-layout, on ratatui. The surface where a fill can vanish: two intents that differ in 24 bits can land on one entry in 16 colours, so depth degrades from colour to structure.
Documentation
# makeover-tui

The terminal renderer for
[`makeover-layout`](https://makenot.work/git/max/makeover-layout), on ratatui.

Named for the target and not for the library, the same way `makeover-immediate`
is named for the mode and not for egui.

## What a terminal changes

A terminal *can* paint a two-tone bevel, which is the surprise. Writing cells
directly gives per-side colour control that neither ratatui's `Block` nor egui's
single `bg_stroke` offers, so the lit edge that a webview does with
`box-shadow: inset` and egui does with two polylines is available here too.

What a terminal cannot reliably do is fill. Two surface intents several steps
apart in a 24-bit theme routinely land on one entry in sixteen colours, and
`surface-well` collapses onto its own face on 18 of the 31 shipped themes. A
well drawn as a fill is then a well drawn as nothing.

So depth degrades from colour to structure: paint the fill when it will be
visible against what is already in the buffer, and always paint the edge,
because the edge is the part that survives. `Palette::shows` is the whole of
that problem in one predicate.

The other terminal-only fact: an edge costs a cell on each side. `frame` returns
the area left for content rather than letting a caller assume the region is
intact.

## The correction it forced

`makeover-layout::Fill` briefly carried a `fallback`, returning `Page` for
`Well` so a consumer without `surface-well` had something to paint. That is an
answer for a renderer that can always paint an exact colour. Here it is actively
wrong: the page is usually the surface a well is cut *into*, so falling back to
it produces precisely the invisibility the fallback existed to prevent.

Substituting one intent for another turned out to be renderer policy rather than
description. It moved out of `makeover-layout` and into `makeover-immediate`,
which does want it. That is the first thing a second renderer was built to find,
and it took a day rather than the API-window's usual 48 hours after adoption.

## Status

Unpublished, path dep on `makeover-layout`. No consumer yet: alloy_tui and shop
are the intended first ones, both of which already take makeover and
makeover-geometry from the registry.

Design lives in the wiki note `makeover-tui`; the backlog is in GoingsOn under
the project of the same name.

## Licence

MIT.