[Idea] Scroll overview track for ScrollView

[robfeldmann]

This is a post-1.0 idea. Tessera 1.0 scope is already set, and this does not change it.

Problem or user need

A long scrolling view gives little sense of where the reader is. In a diff, a log, or a
search result list, users must scroll to find the changes or hits. A thin track beside
the content, like the minimap in many editors, shows the whole document at a glance. It
marks where changes and matches are, and where the visible window sits.

Proposed behavior

Add an optional overview track to ScrollView:

ScrollView(axis: .vertical, overview: .marks(model.matchRows)) {
    ForEach(model.lines) { LogLine($0) }
}

The track is one column wide. It uses the same rows for every document length:

• Each track row covers a bucket of content rows. The bucket is painted with the most
  important mark inside it. A removed line outranks an added line, which outranks a
  match.
• The visible window is shown as a lighter band.
• Clicking or dragging on the track scrolls to that bucket.
• The track reserves its column only when the app turns it on. Other layouts do not
  change.

omp2 does this in its diff pane. A Minimap option reserves two body columns, and
each track row paints two buckets with a half block. The first bucket is the top half
and the second is the bottom. Deletions win over additions, and the visible range is
lightened
(diff_pane.rs).
Tessera should offer the track as a generic ScrollView feature, not as a
diff-only control. The mark source is the app's choice.

Why this belongs in Tessera

• It answers "where am I?" in long lists without adding a second view.
• The bucket rule keeps output stable as the document length changes.
• Mouse support follows the existing controlled-scroll model, where the app owns
  the offset.

Alternatives considered

• Show a scroll percentage in the status bar. This is cheap, but it does not show
  where the changes are.
• Let each app draw its own track. Every app would repeat the bucketing and the
  priority rules.
• Mark every row. For long documents, this does not fit in one column.

Scope and compatibility

Additive. It is opt-in and changes nothing when off. It depends on the ScrollView
offset and content-size model, and on the controlled-scroll binding. Marks come from
the app as an array of row indexes and kinds. The track needs its own hit region, so
it depends on the planned mouse-handling slice.

Checks

• I searched existing Issues and Discussions for this idea.
• I understand that this Discussion does not reserve the work or approve a pull
  request.
• I did not include credentials or other sensitive information.