Visual editing for pages built with blocks: nested fields in place, one publish per page, block actions

[DiogoDuart3]

In 1.1.0 the edit-mode toolbar only edits top-level fields: getFieldKind(manifest, collection, field) looks the field up by name, and saveField sends { data: { [field]: value } }. On a page built with a blocks field (or with repeaters), every click opens the admin, so a page builder can't be used on the page. We run a ~250-line patch of packages/core/src/visual-editing/toolbar.ts in production and would like to upstream it. Proposal in steps:

1. Field paths for nested values. layout.<_key>.<field> addresses a block field by the block's stable key, and <field>.<index>.<sub> a repeater item, nested in any order (layout.<_key>.items.0.title). The kind is resolved through the manifest: the stored block's _type/_version gives the block type version, a repeater gives its sub-fields. The stored value is read through the path, for the "shown as stored" check and the image popover. A save reads the latest data (draft included) and PUTs the whole top-level field with the one value replaced, keys kept. Templates need a way to emit these, e.g. entry.edit.at("layout", block._key, "heading") or entry.edit["layout.<key>.heading"].
2. One Publish per page. A page often shows fields of several entries (the page plus shared settings). Today Publish acts on the entry saved last, and the status badge reads only the first annotation. Proposal: collect the distinct annotated entries, show "unpublished changes" if any has a draft, and publish all of them with one confirmation that names them.
3. Translated toolbar. Badges, save states, the image popover and the media browser are fixed English strings; they belong in ToolbarLabels with catalog messages, like publish/editMode.
4. Line breaks in text fields. An element whose only extra children are <br> still shows the stored text; compare through editableText instead of opening the admin.
5. Block actions on the page (larger, for discussion). An annotation per block (data-emdash-block='{"field":"layout","key":"…"}') on which the toolbar draws a small bar: move up/down, duplicate, hide, delete, and "insert block here" with the admin's picker, saved through the same content PUT with _version from the block type and keys preserved.

Questions: should nested paths become part of entry.edit's public API? Should publish-all be the default when several entries are annotated? Should block actions live in the core toolbar or be opt-in per field?

If parts 1 to 4 are agreed, we can open them as separate PRs.

Drafted with AI assistance (Claude Code), from a patch we run in production on 1.1.0.