feat(node-type-registry): sync the CheckOwnedRelation node type from constructive-db

[pyramation]

Summary

Brings the published registry up to date with CheckOwnedRelation, shipped in constructive-io/constructive-db#3270, so blueprint authors get the type. constructive-db's private registry must stay a superset of this one, and its blueprint types are generated from these definitions — without this entry { $type: 'CheckOwnedRelation', data: … } is a type error against the published package.

CheckOwnedRelation declares that typed pointer columns may only reference rows owned by the same scope owner as the referencing row, proven through a link table carrying (owner_scope, owner_key) — typically a catalog projection that must never be referenced structurally, so no FK can express the constraint. It is also the write-path complement to RLS, which scopes what a caller may see and write but cannot stop a legitimately-scoped writer from pointing at a row in another scope.

Two things worth knowing beyond the diff:

• It redefines the Check* prefix. The other four Check* nodes compile to a table CHECK constraint; this one emits a BEFORE INSERT OR UPDATE trigger, because a CHECK cannot read another table. Check* now means "validation", not "CHECK constraint".

• arity is what makes it cover every relation shape. The guard lives on whichever table carries the pointer, so belongs_to / has_one / has_many are the row being written and has_and_belongs_to_many is the junction row:

  arity	rule	shape
  exactly_one (default)	exactly one pointer non-null	polymorphic target (route → api OR site OR bucket)
  all	every pointer non-null	junction row of a habtm; mandatory belongs-to
  any	no arity rule; each pointer still checked when set	optional pointers

Definition copied verbatim from constructive-db's packages/node-type-registry/src/data/check-owned-relation.ts; blueprint-types.generated.ts is regenerated with pnpm generate:types (99 node types), adding CheckOwnedRelationParams and the CheckOwnedRelation arms of BlueprintNodeShorthand / BlueprintNodeObject. No generator behavior lives in this repo — the SQL is emitted by metaschema_generators.check_owned_relation in constructive-db.

Link to Devin session: https://app.devin.ai/sessions/50d7f9c53d1c4a5ea0092cd47a90fcb7
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, CI, and merge conflict monitoring