refactor(provision): cross-relations via provisionBlueprint() (drop raw SQL)

[pyramation]

Summary

Converts packages/provision/src/schemas/cross-relations.ts from raw pool.query('SELECT metaschema_modules_public.provision_relation(...)') calls into a declarative BlueprintDefinition that rides the same provisionBlueprint() path as every other schema in this package.

• 21 M:N junctions + 7 cross-schema BelongsTo FKs are now emitted as typed BlueprintRelation[] entries ($type: 'RelationManyToMany' | 'RelationBelongsTo') with source_schema_name / target_schema_name = 'app_public' for disambiguation (e.g. emails also exists in user_identifiers_public).
• Drops the ~80 lines of scaffolding that did: pg.Pool instantiation, schema-id lookup, per-call resolveTableId, per-relation try/catch, and a post-hoc DISABLE ROW LEVEL SECURITY loop on each junction table.
• Motivation: Dan flagged that cross-relations.ts was the only other place in this package using raw SQL to drive provisioning, violating the "SDK / blueprint only" convention. This finishes the cleanup started in feat(provision): upgrade to latest PostGIS spatial-relation stack + 5 RelationSpatial entries + ORM tests #24 (spatial-relations).

No behavioral intent change — same 21 junctions, same 7 FKs, same delete_action / is_required values. Server-side construct_blueprint dispatches to provision_relation(...) the same way the old raw SQL did.

Review & Testing Checklist for Human

• Idempotency on re-provision. The old code caught "already exists" errors per-relation so re-running against a populated DB was a no-op. The new path lets provisionBlueprint build one blueprint record and call construct_blueprint once — if any relation is a duplicate, confirm construct_blueprint tolerates it or that the overall run is still safe. (CI pgpm-deploy provisions a fresh DB, so it only exercises the first-run path.)
• RLS posture on junction tables. The removed loop was explicitly disabling RLS on each junction after creation. This PR relies on the global "disable RLS on all app_public tables" step already present in provision.ts to cover them. Worth confirming the junctions land in app_public (not some other schema) so the global sweep catches them.
• tables: [] is accepted by the server. The old code carried a comment claiming blueprint validation "requires non-empty tables array". I believe that's stale (resolve_blueprint_table falls back to existing tables by name, and PR feat(provision): upgrade to latest PostGIS spatial-relation stack + 5 RelationSpatial entries + ORM tests #24's spatial-relations uses the same empty-tables pattern and passes CI). Please sanity-check the deployed @pgpm/metaschema-modules version matches.
• CI green: pgpm-deploy, orm-tests, cli-e2e-tests, embedding-*.

Notes

• delete_action types tightened to the 5-char union ('c' | 'r' | 'n' | 'd' | 'a') that RelationBelongsToParams declares. Existing values are all 'n' or 'c', so no logical change.
• The pre-existing pnpm build failure on main (stale ref / source_ref / target_ref usage in the wrapper blueprint.ts vs the published BlueprintDefinition type) is unrelated and not addressed here.
• Follow-up Dan asked about separately: pushing a source_field / target_field addition onto the RelationSpatial arm of BlueprintRelation inside node-type-registry so agentic-db can drop the local SpatialRelationEntry cast added in feat(provision): upgrade to latest PostGIS spatial-relation stack + 5 RelationSpatial entries + ORM tests #24. Will be a separate PR against constructive-io/constructive.

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