feat: move node-type-registry to graphql/ and update for blueprint redesign

[pyramation]

Summary

Two changes across multiple commits:

1. Relocates node-type-registry from graphile/ → graphql/ (pure rename for all 66 source files; both dirs are in pnpm-workspace.yaml).

2. Updates blueprint TypeScript types to match the server-side redesign in constructive-db PR #721:

   • BlueprintTable.ref removed — table_name is now the identifier
   • Optional schema_name added to BlueprintTable, BlueprintIndex, BlueprintFullTextSearch
   • source_ref/target_ref → source_table/target_table on BlueprintRelation (+ optional source_schema_name/target_schema_name)
   • New BlueprintUniqueConstraint type (table_name, columns[], optional schema_name)
   • BlueprintDefinition.unique_constraints added

Both the codegen script (generate-types.ts) and the generated output (blueprint-types.generated.ts) were updated. tsc --noEmit and pnpm build pass on the package.

Breaking: any consumer code referencing ref, source_ref, target_ref, table_ref, or BlueprintPolicy.policy_type will need updating.

Updates since last revision

• Three-tier blueprint definition support: Added table-level type variants — BlueprintTableIndex, BlueprintTableFullTextSearch, BlueprintTableUniqueConstraint — that omit table_name (inherited from parent table). BlueprintTable now has optional indexes[], full_text_searches[], and unique_constraints[] arrays using these nested types. This matches the three-tier definition model in construct_blueprint (Tier 1: Data* nodes, Tier 2: table-level arrays, Tier 3: top-level arrays).
• Fixed BlueprintPolicy.$type: Changed policy_type → $type to match the actual blueprint JSON convention. The SQL procedure reads v_policy_entry->>'$type', not policy_type. The old type was incorrect. The generator (buildBlueprintPolicy) now always uses the static definition rather than introspecting the DB policy table (which has the column named policy_type, but that's the DB schema — not the blueprint JSON shape).
• Added pnpm-lock.yaml regeneration (fixes ERR_PNPM_OUTDATED_LOCKFILE in CI).

Review & Testing Checklist for Human

• BlueprintPolicy.$type breaking change: Any code using BlueprintPolicy.policy_type must switch to $type. Search for policy_type in consumer code. The SQL has always expected $type, so the old type was a bug — but consumers may have been working around it.
• Downstream consumer breakage: sdk/constructive-cli/src/public/cli/commands/node-type-registry.ts and any other packages importing BlueprintTable, BlueprintRelation, BlueprintIndex, or BlueprintFullTextSearch were not updated in this PR. Search the monorepo for usages of the old field names (ref, source_ref, target_ref, table_ref) and verify they are updated before merging, or accept that this is an intentional breaking change to be fixed in a follow-up.
• Companion PR alignment: Verify this merges in coordination with constructive-db #721 — the types here must match the JSONB shape that construct_blueprint() expects on the server. In particular, confirm the three-tier merging (table-level + top-level) and the $type convention on policies are consistent.
• Lockfile churn: The pnpm-lock.yaml diff is large due to format changes (likely a pnpm version difference). Verify no unintended dependency additions or removals.

Suggested test plan: After merging both this PR and constructive-db #721, run cd graphql/node-type-registry && pnpm generate:types and confirm the output matches the committed blueprint-types.generated.ts. Then pnpm build at the workspace root to verify no downstream compile errors.

Notes

• The package.json name (node-type-registry) is unchanged, so bare-name imports (from 'node-type-registry') should resolve via pnpm workspaces regardless of directory.
• Node type definitions themselves (authz, data, relation, view) are untouched — only the blueprint structural types changed.
• The graphile-settings CHANGELOG references node-type-registry but that's just prose, not an import.
• buildBlueprintPolicy in the generator intentionally skips the introspection-driven path now. The metaschema_public.policy table has a policy_type column, but the blueprint JSON convention uses $type as the discriminator (matching nodes and relations). If new fields are added to the policy table that should surface in BlueprintPolicy, they'll need to be added to the static definition manually.

Link to Devin session: https://app.devin.ai/sessions/094d88b562a04a2fa55dc2e4d85f7b8d
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

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request