Nested-element re-targeting isn't detected for nested sourced_from fields

## Background

`sourced_from` lets a field on an indexed type be populated from a *different* source type's events. https://github.com/block/elasticgraph/pull/1252 extended this to fields on **nested elements** of a document.

`sourced_from` forbids a source from changing which target it feeds. `validateSource` (`index_data.painless`) enforces this for the top-level case: it rejects an event whose relationship has "apparently changed," since allowing it would break out-of-order processing guarantees.

## Problem

The guard doesn't catch the nested analog — a source re-targeting from one nested element to another.

It works per `sourceKey`, which for a nested event encodes the relationship **plus the target element's identifiers**. A source moving from element A to element B writes to two different `sourceKey` buckets, and the guard only compares source ids within a single bucket — so it never sees the move, and the re-target is silently accepted.

## Question to resolve

Top-level relationship mutations are rejected; nested-element re-targeting currently isn't. Should it be — and if so, how, given that detecting it means looking across `__versions` buckets for the same source id rather than within one?

Start by reading validateSource in index_data.painless and trace how sourceKey and __versions buckets represent nested sourced_from relationships. Compare the existing top-level mutation guard with nested-element events, then determine the intended behavior for a source moving between elements. Done means the behavior is decided and the nested re-targeting case is covered.

Written by the indexing model from the issue text.