Rebuild the editing UI around one tool per tap, and sell it by the tool

[andiwand]

The strip under the edit bar was up to eleven targets wide and scrolled on a phone. Every marking tool carried a second button just for its colour, and undo and redo sat at the end, where a pdf's five tools pushed them off the screen.

The strip is formatting alone

	before	after
text document	Pro badge, B/I/U/S, colour, highlight + chevron, "Text size", undo, redo	B/I/U/S, colour, highlight, size
pdf	five tools, each with a chevron, undo	five tools
sheet, plain text	a strip holding only undo and redo	none

Undo, redo and save are menu/edit.xml now, so they stand in the bar and cannot scroll away, and EditActionModeCallback dims them on what the page reports. The bar's title is the mode's name - three buttons leave a phone no room for a sentence.

The colours are on a long press. A tap does the tool's one job; the bar under the icon is the colour the next tap uses. Text colour is the exception and opens its colours on a tap too, because it has nothing to toggle, so nobody is stranded who never finds the long press. The press carries an accessibility action label built from the tool_color_of string the chevrons used.

The bar sits at the foot of a deep slot. Close under the icon, an icon's own shape decides the gap - a squiggle dips, a strikethrough stops high - and 3dp of clearance made that read as bars at different heights. Measured on a device the bars were always level to the pixel; the gap ran from 11px to 21px. Away from the ink the eye lines them up against each other instead.

The font sizes are a row, not a menu. Fourteen items down the screen covered the document they were about; the row scrolls to the size the text is in.

A pdf's tools mark what is selected

odr.annotation.press marks a standing selection and arms only what it could not mark, so PageView.pressMarkTool puts every tool but the pen back down and reports what happened. With nothing selected the answer is the action_annotate_banner snackbar, not a tool left armed. The page's own markOnSelection is off: it marked as the selection was made, which is the opposite order.

The gate is on the tool, not the mode

Every edition opens every kind the core calls editable. A locked strip dims what only offers pro and leaves the highlighter working, under both names it has - highlight is the formatting style and the pdf's marking tool alike. A mode nobody can do anything in is not worth opening, and a reader who has highlighted a paragraph knows what the rest would do.

Both offer strings were reworded, and their translations dropped rather than left stating the old, now false, thing.

Wants a core release. The free highlighter in a text document needs opendocument-app/OpenDocument.core#909, which is unreleased. Against 7.1.0 the page refuses it and the offer of pro comes up, as it does today - but gradle/libs.versions.toml should carry a core with #909 before this ships.

No string is new: every label reuses one the app already has in nineteen languages, and action_edit_banner is gone from all of them.

Checked

On a Pixel 6 Pro emulator, light and dark, pro and lite, and by hand on a Pixel 9 Pro: 97 instrumented tests on pro, 97 on lite, the unit tests, lint, and all three flavors build. MainActivityTests.onlyThePenStaysArmed is new and pins the marking rule and the gate.