Decide load_related membership against final state (#6548)

* graph: Fix load_related returning stale or phantom derived entities

EntityCache::load_related decided derived field membership against
intermediate cache layers, so same-block changes to an entity's parent
reference could leave it in the wrong derived collection (or omit it
from one it had moved into). Rewrite load_related to build a candidate
set from the store baseline plus in-block writes, resolve each
candidate's final state by layering store -> updates -> handler_updates
the same way get() does, and apply query.matches exactly once against
the final state.

* graph, store: Add tests for load_related under same-block membership changes

Cover six scenarios where an entity's parent reference or presence
changes within a block: a single-handler reassignment that should
remove the entity from the old parent's derived collection, a
cross-handler reassign-then-revert that should leave the intermediate
parent's collection unchanged, a cross-handler touch-then-reassign
that should add the entity to the new parent's collection, a removal
landing in updates and a removal landing in handler_updates that both
drop the entity from its collection, and a fresh in-handler creation
that should appear in the new parent's collection.

* graph: Avoid cloning keys when building load_related candidate set

Hold borrowed `EntityKey` references in the candidate `BTreeSet` instead
of cloning into owned keys. The keys borrow from `stored`, `self.updates`,
and `self.handler_updates`, all of which outlive the candidate set.