Closes #1281 — please read that first for the motivation. Opening this as a draft: it is a concrete suggestion to argue about, not a merge request. Happy for the team to take the idea and implement it their own way.

What

Adds one action to the canvas extension channel, selectSection, backed by a selectSection(view, sectionIndex) helper in editor-utils/blocks.js.

Why

A BYO panel extension can already read the document (the handshake hands it { org, repo, ref, path } and the IMS token, so it can fetch page source from admin.da.live) and insert into it (sendHTML → insertHTML). What it cannot do is move the selection, and that blocks two things:

1. Jumping the canvas to a section. A plugin listing the page's sections cannot scroll the editor to one when clicked, the way ew-page-outline does.
2. Editing an existing section. insertHTML does replaceRange(from, to, …), so the edit loop already works — it just needs something to put the selection on the right node first. Without that the only remaining route is writing source via admin.da.live underneath a live collab session, which we are deliberately not doing.

Selecting the whole section rather than only scrolling to it is the load-bearing choice: it delivers the jump and leaves a replaceable range under the existing sendHTML, so editing needs no second API.

Implementation notes

• getSectionRanges reuses the same "split top-level nodes on horizontal_rule" walk that deleteSection and moveSection already use, rather than introducing a second notion of what a section is.
• Ends in TextSelection + scrollIntoView() + view.focus(), mirroring what the outline path does.
• Replies on the port with { action: 'selectSectionResult', details: { ok } } so a plugin can feature-detect and degrade rather than fail silently — our prototype shows an explicit "this host does not support it yet" note on timeout.
• Nothing here lets a plugin mutate the document outside the editor. Edits still go through ProseMirror and collab.

Open questions for the team

• Address shape. sectionIndex is what the existing block/section helpers already speak, but a prose-index or node address would be more general and would survive section reordering better. Happy to change.
• Naming / placement. selectSection sits alongside the other verbs in iframe-protocol.js; if extension capabilities are meant to be gated or declared per plugin, this should probably go through that instead.
• Should a read-only variant exist (scrollToSection) for plugins that want to navigate without disturbing the user's selection? We did not add one because the replaceable range is the point, but the two uses are separable.

Testing

Verified against a real customer page in a local canvas: clicking a section in a plugin panel scrolls the editor to it, and a subsequent getSelection → edit → sendHTML round-trips the section's prose HTML — preserving block content and any non-audience Style tokens, and updating only what the plugin intended.

This is driven by an authoring plugin we built for section-scoped personalization; happy to share it if that helps evaluate the shape.