act on a page selection from the rail, and say what it covers

[lightglitch]

Problem

Selecting several pages in the page rail gives no running total. The selection is visible only as highlighted rows, so on a long rail there is no way to tell how many pages are selected without counting them.

The same information is missing where it matters most. Export PNG and Export PSD act on the selection, falling back to the active page, but the menu entries do not say how many pages they will write. A selection made in the rail becomes invisible at the moment of exporting, which is exactly when its size matters.

Acting on that selection is also a round trip. Processing or deleting pages means leaving the rail for a menu, even though the pages are already under the pointer and already selected.

Proposal

Make the rail say what is selected, and let it act on the selection.

The selection is stated where it is made

• The header shows N selected above the filter once more than one page is selected.
• The PNG and PSD export entries show the same count.

The rail can act on pages

• A process button in the header runs the same command as Process -> Selected Pages when more than one page is selected, and Process -> Project otherwise.
• A delete button beside it deletes the selection, or every page when there is no multi-selection. It asks first, naming the count, since it is bulk and destructive and sits next to a button that starts a pipeline run.
• Each page row reveals a process button on hover that runs only that page.

Scope belongs to the header and a row means the page it sits on. Both header buttons follow the selection the same way, so the two read alike, and their tooltips and accessible names say which of the two they will do before anything happens.

A single selection is left unannotated: it is the ordinary case, and it behaves the same as acting on the active page, so a 1 page badge would only add noise.

Proposed acceptance criteria

• Counts are derived from the value the commands actually receive, so what a control says cannot disagree with what it does.
• The rail indicator is announced to assistive technology when it changes.
• The process buttons are unavailable while a run is in flight, since the backend refuses a second one.
• Deleting asks for confirmation and names what it will remove. It stays undoable, as page deletion already is.
• Nothing changes when zero or one page is selected, beyond the buttons meaning the whole project.
• No backend or protocol change: every command already exists.

Product scope questions

A previous implementation of the count alone was submitted as #1010 and closed because this product behavior had not been agreed with maintainers first. I am opening this issue before requesting review again, and have widened it because the count and the buttons are the same question: what the rail knows about a selection and what it lets you do with it.

1. Is a selection count wanted in the rail header, or would you rather it live in the status bar?
2. Should the export entries carry the count, or is the rail indicator enough on its own?
3. Are process and delete buttons wanted in the rail at all, or should those stay in the menus?
4. Is following the selection the right behaviour for the header buttons, or should they always mean the whole project?
5. Should the header hold both buttons, or is delete too destructive to sit one icon away from a pipeline run?
6. Is "more than one" the right threshold throughout?

Screenshot in a comment below.

[lightglitch]