feat: add start/end node markers (v0.3)

[handlename]

Why this change

Existing workflows require deleting and re-adding nodes when debugging a partial flow, since the entry point was implicit ("the node with no incoming edges"). This forces destructive edits and makes restoring the workflow tedious.

v0.3 introduces explicit start/end markers as Canvas text nodes:

• runestone:start marks the entry point. Moving its outgoing edge re-routes the workflow without deleting any nodes.
• runestone:end (optional, zero or more) halts the workflow gracefully when reached — useful for stopping execution at a checkpoint during debugging.

Approach

• Markers are payloadless text nodes identified by literal runestone:start / runestone:end content (no frontmatter, no body). Chosen over file-node markers to keep them lightweight and visually distinct from runnable nodes.
• The implicit "no incoming edges = start" rule is removed entirely. This is a breaking change — accepted because the plugin is still in beta and the partial-execution UX gains outweigh the migration cost.
• end semantics chosen as halt-workflow (graceful): reaching any end stops new scheduling, but in-flight exec/script nodes complete naturally so their output remains in the Log Panel.
• Internal representation uses a discriminated union WorkflowNode | MarkerNode exposed via isMarkerNode / isWorkflowNode type guards. Markers are excluded from ExecutionState.entries (no payload to track) and visualized via a dedicated CanvasVisualizer.updateMarkerNode path.
• Marker color lifecycle: start (running 5 → success 4 on completion); end reached → success 4; end unreached → skip 0.

Migration

Existing workflows must add a runestone:start text node connected to the original entry point. The bundled example workflows (vault.example/workflows/*) have been migrated, and the now-redundant start.md exec nodes (whose only purpose was to be the implicit start) have been removed.

See MIGRATION.md for the full migration guide.

Acceptance criteria

All criteria from the spec are covered by tests:

• A1–A7: validator rules (start count, edge constraints, end validation)
• B1–B4: text-node marker parsing
• C1–C7: executor behavior (start propagation, end halt, args independence, parallel start)
• D1–D5: visualizer marker color path (dedicated unit tests omitted; DOM-mock cost prohibitive — behavior validated manually against the example workflows)

npm test: 183/183 passing. npm run build and npm run lint clean.

Review notes

• The biggest design call is graceful halt on end-reach: in-flight nodes complete instead of being killed. This avoids child_process.kill() complexity and the inability to cancel AsyncFunction cleanly. Worth a sanity check.
• validator.ts was rewritten — the template-reference check now targets start-adjacent successors (instead of the start node itself, since markers have no body).
• The MarkerNode discriminated union ripples through several files (parser, builder, validator, executor, execution-state, run-canvas). The fan-out is deliberate; the type guards keep the WorkflowNode-specific code paths cleanly narrowed.