RemoteGraph has no base-graph vs view distinction, unlike the local API

Raised from review on #2707: https://github.com/Pometry/Raphtory/pull/2707#discussion_r3802677910

What

Locally, a base graph and a view are different classes, and that split carries real meaning:

Remotely there is only RemoteGraph. Every handle — base or view — is the same class, so both the mutators and the flavour conversions appear on views too, where they are not meaningful.

Why it matters

The distinction currently has to be enforced at runtime and explained in prose. For example RemoteGraph.event_graph() documents its own restriction in the docstring:

Only valid on the base handle (as locally, where the conversions live on the graph classes rather than on views).

and raises if called mid-chain. Locally the same rule needs no words and no runtime check, because GraphView simply does not have the method.

That makes the remote API harder to document accurately (the stubs advertise methods that only work on some instances) and pushes a class of mistake from compile/lookup time to runtime.

Suggestion

Split the remote handle so views are a distinct type from the base graph, mirroring the local class layout, so:

• the mutation surface and the flavour conversions exist only where they apply
• the generated stubs describe each type accurately
• the runtime guards and the prose caveats can go away

Noted at the time as for the future, not that critical — filing so it is not lost.

Start by locating RemoteGraph and the local Graph, PersistentGraph, and GraphView definitions, then trace event_graph(), persistent_graph(), and the generated stubs. The work is done when remote base graphs and views are distinct types, with mutations and flavour conversions exposed only on applicable types and the runtime guards and prose caveats no longer needed.