* fix(ok): draw every dialog footer button in one typeface

About half the dialog footers drew their dismiss button in the UI sans face while the confirm button beside it was monospace and uppercase, so a single row of buttons read as two type systems. The cause was that four spellings of the same treatment coexisted: the outline-mono variant, a hand-typed font-mono uppercase className, one baked into AlertDialogCancel, and another baked into DialogClose. Half the call sites picked one of them and half picked none.

DialogFooter and AlertDialogFooter now impose the treatment on the buttons they contain, so a call site cannot get it wrong by choosing a variant. The four spellings collapse to that one, which removes 29 hand-typed classNames across 19 files.

The no-demoted-dialog-confirm docstring said the treatment comes with the variant. That is no longer how it works, so it now points at the footer.

* fix(ok): repoint the trash-modal assertion at the footer that owns the treatment

TrashFailureModal.dom.test.tsx asserted font-mono on the cancel and retry buttons' own class attributes. The treatment moved to the footer, so both went red and test:dom is in the pnpm check gate. The assertion now reads the footer element instead. Running only the two dialog suites rather than the whole tier is how it got missed.

The e2e assertion in okf-generated-index-settings covered the confirm button, which bakes the treatment into its variant and never changed. It now covers the cancel button too, which is the one that depends on the footer selector, and e2e is the only tier that reads the compiled stylesheet.

biome-plugins/README.md still said the treatment comes with the variant and that DialogClose hardcodes it, which this branch removed. That paragraph is what the rule's own diagnostic links to. It now describes the footer as the source, records that the footer outranks a button's own class so opting out needs font-sans! or normal-case!, and states that a non-button footer action styles itself.

Renamed an alert-dialog test whose name promised cascade coverage that jsdom cannot provide.

* fix(ok): cover Button-as-anchor in dialog footers and decouple the consumer test

The footers now key on both the button element and [data-slot=button]. Neither predicate covers every footer shape on its own: the AlertDialog wrappers and DialogClose stamp their own data-slot so a slot-only selector misses them, while Button asChild rendering an anchor is not a button element so a tag-only selector misses that. Verified against the rendered DOM for all five shapes, and against the compiled stylesheet that Tailwind emits both rules.

TrashFailureModal.dom.test.tsx asserted the footer's own arbitrary-variant literal, a third copy of a pair the two ui suites already pin, and had lost the retry coverage the previous assertion gave it. It now asserts only what this consumer owns: that all three actions resolve to the same footer. That also removes the coupling that would have reddened this file when the selector changed.

The README and the docstring were missing outline-mono from the list of variants that bake the pair, and described the carve-out on the tag axis, which misreads Button asChild as a non-button action. Both now state the condition rather than the current instance.

GitOrigin-RevId: ead5d93322050c09a3f613652ab5ca5a5ef2e853