Add browser-native WASM binding for local GraphForge execution

[DecisionNerd]

Goal

Add a browser-native WebAssembly binding for GraphForge so graph data, queries, and algorithms can execute entirely on the client without sending user data to a server.

Core product promise: the graph never leaves the browser.

This should be a distinct browser target, not an attempt to make the existing Node native binding run in browsers.

Motivation

A WASM target would enable:

• Interactive GraphForge demos with zero backend graph execution.
• Privacy-sensitive analysis where source data never leaves the user's device.
• Local Cypher querying and graph algorithms in ordinary web applications.
• Direct integration with graphforge-xy for client-side WebGL visualization.
• A portable local graph runtime alongside the existing Python and Node/native hosts.

This is particularly compelling for investigative/document graphs, legal/discovery data, private organizational data, and other datasets users may not want to upload.

Proposed architecture

Browser
├── GraphForge WASM / Web Worker
│   ├── in-memory graph
│   ├── Cypher parse/plan/execute
│   ├── traversals
│   ├── selected native algorithms
│   └── graph/visualization projections
│
└── graphforge-xy
    ├── Rust layout / LOD / encoding
    └── WebGL rendering

Prefer running GraphForge WASM in a Web Worker so query and algorithm execution cannot block the UI thread.

The integration path should avoid JSON/object materialization for large graph results where possible. GraphForge and graphforge-xy should exchange compact typed/binary representations suitable for direct WebGL consumption.

Initial browser profile

Candidate MVP support:

• Compile reusable GraphForge core crates for wasm32.
• Browser-facing JS/TypeScript API generated from a dedicated WASM binding.
• In-memory graph creation/import.
• Property graph access.
• Core Cypher MATCH / WHERE / RETURN execution.
• Traversals and shortest paths.
• Connected components.
• PageRank / ranking algorithms where practical.
• Community detection where practical.
• Typed/binary result transport.
• Web Worker reference integration.
• Integration contract for graphforge-xy.
• Demo proving that graph data and query execution never leave the browser.

Explicit non-goals for MVP

• Native disk-oriented storage parity.
• Reusing the Node native addon in the browser.
• Full Python/Node API parity on day one.
• Requiring WASM threads before the single-threaded browser target works.

Follow-on

After a single-threaded WASM target is stable, investigate WASM threads / SharedArrayBuffer under cross-origin isolation for parallel GraphForge execution.

Acceptance criteria

A static/demo web application can load a non-trivial graph locally, execute a GraphForge query and at least one native graph algorithm in-browser, pass the resulting graph projection to graphforge-xy, and render it interactively without transmitting graph data or query execution to a backend.