fix(reasoner): store business id as property on DDL-created vertices

[JJUN99]

Symptom

Events created by a concept rule's Action block (createNodeInstance) never receive their belongTo classification, and concept-level propagation over them silently stops. No error is visible in docker logs or in the client response — the exception only appears in the server's common-error.log.

Root cause

ExtractVertexImpl.extractVertex() computes a business id for the new vertex (either from the id entry in the Action's value map, or by concatenating the internal ids of all pattern-bound vertices) but only uses it to build the internal IVertexId. The vertex property map never gets an id entry.

Any subsequent rule execution that uses such a vertex as a start id then crashes while assembling debug info:

java.lang.NullPointerException
  at LocalRDG.generateStartNodeDebugInfo(LocalRDG.java:1461)   // get("id").toString()
  at LocalRDG.getResult(LocalRDG.java:1470)
  at LocalReasonerRunner.doRun
  at InductiveConceptReasoner.reason
  at CausalConceptReasoner.propagate

LocalReasonerRunner.run() catches all Throwables and returns an empty result, so the caller treats the failed run as "0 matches": generated events lose their belongTo classification and causal propagation stops.

Fix

Preserve the computed business id and store it in the vertex property map, matching the shape of vertices loaded from the warehouse.

Verification

Reproduced with the supplychain example (0.8 server): rule ④ (price rise → cost rise) creates 47 CompanyEvent vertices; before the fix all 47 follow-up classification runs died with the NPE above (47 entries in common-error.log, 0 belongTo edges). After the fix: 0 NPEs, 47/47 belongTo edges.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[JJUN99]

I have read the CLA Document and I hereby sign the CLA

[JJUN99]

Note on the failing License Validation check: it dies in the dependency-download step (license-eye dependency check → dependencies download error) before any license analysis runs. The same check also fails on unrelated PRs — e.g. the documentation-only #548 — and hasn't passed on any PR since early 2026, so this looks like a repo-wide CI issue rather than something related to this change (no new dependencies, license headers untouched).