0.4.0 - the chrome row's shape

0.4.0 rebuilds the row of controls along the bottom of a deck.

Someone using 0.2.2 said the back and forward arrows read as an afterthought, and they were
right. The arrows sat between a slide counter and two wide labelled buttons, so the one control
you actually press was the quietest thing in the row.

The ruler, the counter and the arrows now share a drawn box, because between them they answer one
question: where am I, and how do I move. The arrows are filled and nothing else in the row is, so
they are easy to find. Everything else moved out to the right, behind a More button.

Motion is the exception. A deck with looping motion has to keep a visible way to stop it, so that
button stays outside the menu, and moves inside it only in decks with nothing running. The build
decides which, and a check enforces it.

The menu was also rendered open for the first time, which is how a defect nothing measures got
found: a menu item was drawn as a button inside a box. It is drawn as a row now.

Upgrading an existing deck

Your deck will fail the shell check until you migrate it. The report you get first is
NOT A SHELL, which reads worse than it is: it means your shell is one release behind, not that
your file is broken.

What it newly required

The chrome row's shape (T-114). New contracted parts — .navbox, .more, .more-menu and the .btn--pager modifier — and .controls is gone. .chrome carries a twelfth slot, CHROME_TAIL, holding More and, in a deck whose motion loops, Motion beside it. DS-218 is tightened from a control exists to a control not shut inside .more-menu; DS-217's measured bound moves 17 → 16 because the container is drawn. One new token, --more-menu-w. The shared shell moved in all three regions, and then in components.css once more before the tag: a menu item is drawn as a row rather than as a button in a box, which is a look fixed after rendering the menu open for the first time and requires nothing of a deck beyond the sync this row already asks for. T-177 requires nothing of a deck and the row says so rather than leaving it inferred: it fixes tokens --write carrying a dual-band colour's dark value into the light band, which is this repository's own tooling

What newly fails

shell.py check says NOT A SHELL, and that is the whole report — the deck has no CHROME_TAIL anchor, so the cut stops there and the three region failures behind it are never printed. It reads as your file is broken rather than your shell is one release behind, and it is the second. Then, after the repair below and because of it, audit.py — DS-218 on any deck whose motion loops or runs past 5 s, because the migration puts Motion in the menu and a control behind a click is not persistent. Also theme.py / shell.py check — TOKENS, --more-menu-w

The smallest edit

Three commands, in order, and the third is not optional on a deck with looping motion: python tools/deck/shell.py sync <deck> --write installs the anchor and settles the three regions, announcing MIGRATING when it does; python tools/deck/shell.py tokens <deck> --write adds --more-menu-w; then, if anything in the deck loops, python tools/deck/shell.py tail <deck> --loops --write moves Motion out beside More. Verified in that order on a deck built before this change: NOT A SHELL → three regions synced → one token → DS-218 pass

Known, and not fixed here

Past 16 slides the ruler goes dense and the mark for the current slide drops to 7 px beside 14 px
section marks, against 30 px for the ring below that bound. Both rules behind it predate this
release, but this release lowers the bound from 17 to 16, so one more deck length reaches it.
Tracked as T-178.