fix: classify wired nodes without editor x/y as regular nodes, not config nodes

[tbrandenburg]

Issues fixed

Closes #28

Summary

Node-RED's flow parser (@node-red/runtime/lib/flows/util.js) classifies any node lacking both x and y properties as a global config node, regardless of its actual type. Hand-authored --flow-json flows (this tool's core use case — see the README's own agent example) commonly omit those editor-only coordinates. A wired node misclassified as a config node undergoes Flow.js's config-node circular-dependency scan instead of normal instantiation, which throws Circular config node dependency detected the moment one of its own property values equals another node's id — including its own id, e.g. when name equals id (exactly what the README's agent example does). That aborts the whole flow's instantiation, surfacing as target ... is not instantiated, and made the unrelated waitForFlowsSettled() stop/safe race look like the root cause in the original bug report.

Root cause confirmed by:

• reading @node-red/runtime's parser (n.hasOwnProperty('x') && n.hasOwnProperty('y') gate) and Flow.js's circular-dependency scan
• reproducing 100% with core node types only (no external package needed)
• reproducing against the real @tbrandenburg/node-red-agents package from the issue, in a scratch dir outside the repo

Fix

• withDeployCoordinates() in src/run-envelope.js assigns synthetic x/y to every node that's unambiguously wired (has a wires array, or is a link out node) and lacks coordinates, before building the in-memory flow storage module. Genuine config nodes (which have neither) are left untouched.
• Also hardened waitForFlowsSettled() per the issue's own suggested refinement: a stop/safe runtime-state event now defers resolution by one macrotask so an already-scheduled flows:started for the same deploy attempt wins instead — defensive insurance, even though analysis of the installed @node-red/runtime shows stop/safe and flows:started are mutually exclusive outcomes of a single deploy attempt today.

Validation

• node --test test/integration/run-envelope.integration.test.js → 3/3 pass (new issue v0.2.14 regression: flows using the agent node (node-red-agents) now deterministically fail with 'Circular config node dependency' / 'not instantiated' #28 regression test + both existing issue --docker: default ephemeral userDir silently produces empty stdout + exit 0 when target flow references a missing/unregistered node type #23 regression tests, ephemeral and persistent userDir)
• make ci (format + lint + full node --test suite + audit) → 122/122 tests pass, lint/format clean, 0 vulnerabilities

E2E / real-world coverage

• New integration test (test/integration/run-envelope.integration.test.js) reproduces the exact failure end-to-end against the real embedded Node-RED runtime using a minimal self-named link in -> link out flow (no mocks), and asserts a successful deploy + call.
• Additionally manually verified (outside the repo, cleaned up after) against the real @tbrandenburg/node-red-agents@0.4.1 package with the README's own documented agent flow shape: before the fix — Error: Circular config node dependency detected: ask; after the fix — deploy succeeds and the agent node's real execution path runs.

Risks / follow-ups

• withDeployCoordinates() only recognizes a node as "wired" if it has a wires array or is a link out node. This covers 100% of this tool's supported flow shape (link in [-> ...] -> link out), but an exotic node type using neither (e.g. routing purely via links) would still be misclassified as a config node. Low risk given the tool's stated scope.
• Follow-up (not filed as a separate issue, flagging here): the README's own documented agent example is the literal flow shape that triggered issue v0.2.14 regression: flows using the agent node (node-red-agents) now deterministically fail with 'Circular config node dependency' / 'not instantiated' #28 — worth a maintainer look, though no README changes were made in this PR (out of scope).