fix(automation): keep a wrapped problem's bullet on its first line

[rockyway]

Reported against the running build: the bullet for Send to terminal — Add a terminal message or a webhook destination. drew beside webhook destination., with the words it belonged to sitting above it unmarked.

Cause

A <button> is inline-block, and an inline-block's baseline is the baseline of its LAST line box. A problem long enough to wrap gave its li a single line box whose baseline sat on the second line, and an outside list marker is placed on that baseline. The one-line problem above it had no symptom, which is why only one of the two looked wrong.

display: block makes the button's first line the item's first line, so the marker has nowhere else to go. Full width is a bonus rather than a cost — the whole row becomes the click target for the step it focuses.

Third instance of one family

Re-arm now riding high against its state pill, the ⓘ sitting low against its field label, and now this: all inline-level boxes aligned on a baseline that is not where it looks. The first two were fixed in #80 with flex rows; this one is a list marker, so the answer is to stop the button being inline-level at all.

How it was checked

jsdom does not lay out, so a display assertion alone would be a restatement. The fix was verified by extracting the stylesheet's own .au-problems rules and rendering them in headless Edge — before and after, at a width that forces the wrap — which reproduced the reported bullet exactly and then showed it corrected. The test asserts the declaration that makes it true, and dies if the button goes back to inline-block.

Gates

bun run test                                        4190 passed, 236 suites
./node_modules/.bin/tsc --noEmit -p tsconfig.json   clean

No Rust touched.