[Feature]: Resolve related entry fields in nested Current entry field loops

Problem

A nested Current entry field loop can select a multi-relation field, but does not expose the fields of the referenced entries. This blocks a common content workflow: displaying the team members assigned to each offer.

Example content model:

• Offers (angebote): title and a multi-relation field teammembers targeting the Team post type.
• Team: name/title, function/role, and an image.
• Each offer references its own set of team members.

Steps to reproduce

1. Create Team entries with different names, functions, and images.
2. Create two Offers and link different Team entries through teammembers.
3. Add an outer Loop using the Offers table.
4. Inside the offer layout, add another Loop with Source: Current entry field and Field: teammembers.
5. Add Text and Image elements inside the inner loop and open their dynamic field picker.

Actual: the inner source offers generic fields such as Value, Index, and media metadata. It does not offer the related Team entry's name, function, or image. The selected relation identifies a target entry, but that entry's field values are not resolved for binding.

Expected: the inner loop iterates the Team entries linked to the current Offer. Its children can bind to the Team fields, and the next outer Offer uses its own related Team entries. This should work consistently in the editor preview and published HTML.

Reported from a local Docker installation. The code observations below are from checkout 3976035521e9716ac23eac562c5cb9fe5fd4f9d8; this is not a claim that the running image has that exact revision. No new automated reproduction was run for this report.

Proposed solution

Extend the existing entry.field source to resolve schema-declared multi-relations into ordinary target-entry LoopItems, and infer the binding fields from the relation's target table.

Initial code investigation suggests these integration points:

• src/core/loops/sources/entryField.ts: resolveEntryFieldItems currently enriches string references only through mediaByReference; other strings become { id, fields: { id, value, index } }. Add a schema-aware relation resolution path without interpreting arbitrary string-array values as relations.
• src/core/loops/sources/dataRows.ts and the server prefetch/preview path: reuse the existing row projection and media URL resolution for referenced entries. Load required relation targets in batches before synchronous rendering, preserving relation order and the applicable branch/draft/published visibility rules. Avoid one database query per rendered member and unbounded recursive expansion.
• src/core/publisher/renderLoop.ts: pass the resolved relation data into contextual iteration while retaining the current entry-stack behavior, limit, offset, and direction.
• src/admin/pages/site/canvas/useLoopPreviewItems.ts: use the same relation projection for canvas preview so preview and publishing agree.
• Editor loop/binding scope inference feeding LoopPropertiesView.tsx and DataBindingPicker.tsx: follow the selected relation field's target table and expose its bindable fields instead of only generic entry.field metadata. Picker preview values should belong to a linked entry.

This appears to be a read/projection and editor-scope change; existing stored relation IDs should be preserved, with no database schema change needed for the basic case. These are suggested implementation points, not a completed patch.

Suggested acceptance coverage:

• Two outer offers with different related members render only their respective members.
• Related text fields and custom/featured media resolve in both preview and published output.
• Relation order, reverse order, offset, and limit behave consistently.
• Empty relations and missing/deleted/unpublished targets are handled explicitly without leaking draft content to public output.
• Existing multi-media, multi-select, and object-array iteration keeps working.
• Only relation paths actually needed by the layout are expanded, including safe handling of cyclic content relations.

Alternatives considered

A custom plugin loop source was considered, but the current prefetched source context does not receive the active outer loop entry. It cannot directly replace this contextual relation loop without additional host support or restructuring the data source.

A private core patch would require maintaining a custom Docker image across updates. Supporting the existing workflow upstream would be preferable.

Related merged work:

• #299 introduced contextual entry-field iteration and makes multi-relation fields selectable.
• #300 resolves custom media fields to URLs, but does not resolve relation targets.

Area

Visual editor / Publishing