feat(node-type-registry): add RelationSpatial node type (v0.13.0)

[pyramation]

Summary

Adds the RelationSpatial node type to node-type-registry, documenting the parameter shape for declarative spatial relations in blueprints. Consumer-side companion to constructive-io/constructive-db#844, which implements provision_spatial_relation and wires construct_blueprint to dispatch on $type = 'RelationSpatial'.

Changes

• src/relation/relation-spatial.ts (new): RelationSpatial definition. Parameter schema uses UUIDs (source_table_id, source_field_id, target_table_id, target_field_id) matching the node-type-registry convention for other Relation* entries. 8-operator enum (st_contains, st_within, st_intersects, st_covers, st_coveredby, st_overlaps, st_touches, st_dwithin). param_name optional — enforced NULL-unless-st_dwithin by the table CHECK on the metaschema side, not re-checked here.
• src/relation/index.ts: re-export RelationSpatial.
• src/blueprint-types.generated.ts: regenerated via src/codegen/generate-types.ts. Adds RelationSpatialParams interface + a new entry in the BlueprintRelation discriminated union.
• package.json: 0.12.0 → 0.13.0 (new public export → minor bump).

Blueprint author shape

Note that blueprint JSON itself uses names (source_table, source_field, etc.); construct_blueprint on the constructive-db side resolves those to UUIDs before calling provision_spatial_relation. The *_id fields on this node type document the resolved procedure signature, not the author-facing JSON. This matches how RelationBelongsTo / RelationHasOne / etc. are documented today.

Review & Testing Checklist for Human

• Operator enum + param_name rule match the metaschema CHECKs in constructive-db's spatial_relation table (specifically: exactly these 8 operators; param_name required iff operator = 'st_dwithin'). If either drifts, blueprints will be accepted at authoring time but rejected at provision time.
• Generated file is truly generated — src/blueprint-types.generated.ts was produced by running npx ts-node src/codegen/generate-types.ts. Worth a quick glance to confirm the diff looks like codegen output (comments from the JSON-schema descriptions, discriminated-union entry parallel to the other relation types) and not hand-edits.
• Version bump (0.12.0 → 0.13.0) is appropriate for a new public export — no breaking changes in this PR.

Test plan

1. Wait for CI on this PR.
2. Separately, verify the companion PR constructive-io/constructive-db#844 passes CI — that PR's blueprint test exercises a RelationSpatial end-to-end, which is the real validation of the contract documented here.

Notes

• This PR is documentation-only from a runtime perspective — blueprints can already invoke "$type": "RelationSpatial" without it. The node type entry adds TypeScript autocomplete/validation for blueprint authors and lets the metaschema introspection list it alongside the other relation types.
• Deliberately out of scope (per spec): auto-inverse relations (authors write two entries for symmetry), and a st_dwithin default distance arg.

Link to Devin session: https://app.devin.ai/sessions/c5eeee65a3c546c4ac6753bb05fa03e0
Requested by: @pyramation

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring