Decide how to communicate to the user what is getting collected next

A question for Dan, but framed concretely rather than open-ended - the front end has since
grown a partial answer, so the useful question is now whether the shape is right rather than
what to build from nothing.

## What the front end already shows

- **Suggested acquisition path within a square.** `AcquisitionPathOverlay` draws the suggested
order through a square's foilholes, with three switchable presentation styles, gradient
colouring to convey sequence, and explicit markers where the sequence breaks.
- **Suggested squares on the atlas.** Squares the model favours are highlighted at atlas level.

So collection *order* is visualised, at both levels of the hierarchy.

## What it does not show

- Any explicit indication of the **immediate next target** - what the microscope is about to
collect, as distinct from the overall ordering.
- Any sense of **progress through the plan** - what has been collected, what remains, and how
far ahead the displayed plan is still expected to hold.
- Any indication of **how firm the plan is** - whether the ordering shown is a fixed queue or a
ranking that will be recomputed as new predictions arrive. This matters most, because it
determines whether "next" is even a meaningful thing to display.

## The question

Is the existing path and suggestion display what users actually need to understand what is
coming next, or do they need something more explicit and forward-looking?

Specifically, for Dan:

- Do users think in terms of "the next hole", or in terms of "the region being worked through"?
The two imply quite different displays.
- Is a mis-shown "next" worse than showing nothing? If the ordering is recomputed frequently,
an explicit next-target indicator would change often, and could read as instability rather
than as information.
- Does this need to be visible during unattended collection, or only when someone is actively
watching?

## Why it matters beyond display

Users cannot meaningfully reject or override a target they cannot see queued. Answering this is
therefore a prerequisite for the wider user-interaction work, rather than a purely presentational
question - the display decided here becomes the surface those controls attach to.