FaceGraphHost

`IGraphHost` over a face project's mass-spring graph.

In the namespace face. Declared in src/libs/libface/face/FaceGraphHost.hpp.

Detailed description

construct-project-space P13, §PSU-6. `widgets::graph::GraphCanvas` owns the interaction; this owns the model.

What is NOT here, and why the port stops where it does

⚠ This graph's nodes are **mass points** with a `mass` and an `anchored` flag, and it carries **triangles** as a third element type. The parity matrix records that the node MODEL is not unified with libbahn's signal-flow one, and a triangle has no counterpart in a dataflow editor at all.

So `flip`, `flipSelection`, `relax`, `interConnectSelected`, `interTriSelected` and the triangle context menu stay in `NodeView`. The chassis never learns that triangles exist. What it gets is the part that is genuinely the same: hit testing, dragging, panning, zooming, lasso, selection and the menu plumbing.

⚠ **A right-click that hits neither a node nor a connection may still have hit a TRIANGLE.** The chassis calls `populateCreateMenu` for that case, so the `mOnCreateMenu` hook is where `NodeView` decides between a triangle menu and the create menu. Without that the triangle menu would become unreachable, and nothing in the build would say so.