Implement "indirect reverse" fields, those which pass via an EmbeddedMetadata

[apdavison]

#81 implemented #72 for the direct case, where two KG objects are linked.

However, reverse links that pass via EmbeddedMetadata instances are not yet supported.

For example: SoftwareVersion has a field copyright, which contains
embedded metadata of type Copyright (which does not have its own ID).
Copyright has a field holders which links to Person, among others.
At present, it is not possible to access the SoftwareVersion from a Person
by way of a reverse field, since the link is not direct. (You can still make a forward query, though).

[apdavison]

Notes from investigating this alongside the openMINDS reverse-name work
(openMINDS#97), to save re-deriving it later.

The model

Treat an embedded node as an anonymous graph node: no id, but a real node with edges on both sides. We can't resolve to one, but we can express queries that pass via one, and each edge gets its own reverse name:

SoftwareVersion  --copyright-->  (Copyright)  --holder-->  Person
                 <--isCopyrightOf--          <--isHolderOf--

Person.is_holder_of returns Copyright nodes; getting back to SoftwareVersion is a second edge.
This is a smaller change than "indirect reverse properties" implies: nothing has to synthesise a direct Person → SoftwareVersion link.

Most of the machinery already exists

Verified against master (v4 classes):

	works today
expand_filter() __ paths through an embedded node	✅ SoftwareVersion.list(client, copyright__holders=person)
the same, several hops	✅ developers__affiliations__member_of__alias="CNRS" — the docstring example at utility.py:253, which already crosses embedded Affiliation
reverse property names inside __ paths	✅ Person.normalize_filter(expand_filter({"developed__name": "NEST"})) → {'developed': {'full_name': 'NEST'}}
follow_links nesting through an embedded node	✅ follow_links={"copyright": {"holders": {}}} builds a properly nested query
reverse properties across an embedded node	❌ — this issue

normalize_filter iterates cls.all_properties, which chains forward and reverse, which is why reverse names already compose in paths. So the traversal syntax needs no new design.

What is actually missing

The builder never emits these reverse properties. In builder/update_openminds.py:

• get_edges() (~line 997) collects _linkedTypes per schema;
• generate_version() (~line 1041) then drops any of them whose source schema is embedded:
  if link_type not in embedded:.

So two families of reverse property need generating:

1. embedded-source links — Person.is_holder_of → [Copyright].
   Inventory: v4 — 26 embedded types carrying 44 linked properties; v5 — 53 types, 57 properties.
2. containment reverses — Copyright.is_copyright_of → [SoftwareVersion], from
   _embeddedTypes rather than _linkedTypes, which the builder does not treat as edges at all.
   Inventory: v4 — 132 containment properties; v5 — 235.

Names for both families come free from openMINDS#97, which assigns a nameForReverseLink to every property including all embedded-containment ones.

Implementation notes

• The second hop can't be a KGProxy. Embedded instances have no id, so nothing can be fetched lazily. The containment reverse has to be resolved within the same query, or the returned Copyright is orphaned and useless.
• Watch the overwrite in get_edges(). linked[lnk] = (...) is keyed by target type, so within one schema a later property linking to the same type silently replaces an earlier one. Embedded schemas will add many more links to already-linked types, so this will start dropping edges more often than it does now.
• embedded is accumulated incrementally in generate_version() (embedded.update(embedded_in) inside the loop), so whether a link is dropped currently depends on schema file ordering. Removing the filter altogether makes that moot, but it is worth knowing why the current output has a few reverse properties that "shouldn't" be there.
• node.py:336's __ is unrelated to expand_filter's: it splits generated query aliases like holder__Consortium, used when one path yields several types. Embedded traversal will produce more of these, so it's worth a test.

Interactions

• fairgraph#92 — the reverse= cardinality bug is independent of this and should be fixed first; adding ~100 new reverse properties on top of it will multiply the symptom.
• openMINDS#97 — if the names land as proposed, reverse_name_map in the builder retires and both families above get their names from the schemas directly.