Author a VNyan node graph

Builds a node graph from a friendly spec (nodes with caller-chosen ids + literal values, exec/value connections referencing those ids). By default (no 'slot') it EXPORTS the graph as a plain JSON file - import it into VNyan live via its own 'Load Graph' menu (replaces the currently active tab, VNyan stays running, no restart). PREFER THAT even when VNyan is closed: the 'slot' path (redeemsN.json + its asredeemsN.json mirror) REQUIRES VNyan closed and is unreliable, because VNyan persists its own in-memory copy of a tab over the file - a verified slot write has been observed silently replaced by an older graph, surviving only in the asredeemsN.json mirror. If you use 'slot', re-verify after VNyan restarts. Returns a 'warnings' array of static-analysis findings when it spots one of the mistakes VNyan itself accepts silently (a blendshape written twice on one execution path, a parameter read before the node that writes it, a float wired into BlendshapeNode's int value socket, or MathExpNode on a fast timer) - the graph is still written, so read them. Most action nodes have zero execOut sockets (check vnyan_node_schema) - they are terminal, not links in a serial chain. To run several actions off one event/trigger, fan its single execOut out to each action's execIn directly, rather than chaining action-to-action. FAN-OUT EXECUTES IN CONNECTION ORDER within a single tick (multicast delegate), so terminal nodes CAN be sequenced by wiring order - a chain of ParamOpNodes each reading the previous one's parameter resolves in one tick, with no OrderedNode and no lag. You therefore do NOT need MathExpNode to avoid ordering problems, and reaching for it on a timer is a frame-rate disaster - see vnyan_guide topic:'graph-performance'. BlendshapeNode specifics: its wired value socket is cast to int (put a DecimalToNumberNode in front of any decimal source, or the write throws and vanishes), 'bsName' splits on ';' so one node can drive several shapes from one evaluation, and bsValue '0' REMOVES the override rather than writing zero - so never zero a shape and then write it in the same tick. Branching nodes (OrderedNode, every Filter*Node, CompareTextNode, RandomNode, ...) declare their exec outputs as an array sized by the Unity prefab, so vnyan_node_schema reports a floor rather than an exact count - wiring past that floor is allowed for those types, and the sockets are created as needed. Node-value file-path fields (sound/avatar files) can't be set as literals here since VNyan encrypts them - wire a SetTextParamNode/TextReplaceNode into that value socket instead, the same pattern VNyan's own Crowd Control example graph uses. VALUE SOCKETS ARE STRONGLY TYPED AT RUNTIME despite values[] always being strings in the saved JSON - wiring a raw int/text output straight into a float/bool input throws inside VNyan and silently aborts the whole call (see valueConnections.toIndex below). If writing directly to a slot, VNyan only EXECUTES slots covered by settings.json 'NodeGraphCount' - a graph placed beyond that count loads with no error but never runs; use vnyan_settings_get area:'misc' to check it first. If using the default export+Load-Graph workflow instead, note VNyan's live Load Graph updates the running graph immediately but only writes it to redeemsN.json on VNyan's own quit - vnyan_graph_read can lag behind what's actually loaded until then. Full cookbook: vnyan_guide topic:'node-authoring'.