fix: compatible-type foreign keys, search_path setting (4.0.5)

[RiyaSharma03]

Found by running the real coding agent (4-turn project-management app) on rapidnative-website's validator, then checking each rejection against PGlite.

Foreign keys (valid SQL was rejected)

• pg-mem required both FK columns to have the identical type. Postgres accepts any pair with an equality operator: varchar(255) -> text, text -> varchar(50), integer -> bigint, bigint -> integer, integer -> numeric were all rejected here, so a migration like user_id varchar(255) references users(id) failed validation.
• Now accepted when the types share a category, and enforced: key values are converted between the numeric representations (bigint/numeric are digit strings, integer/float JS numbers) for the existence check and for ON DELETE / ON UPDATE actions.
• Incompatible pairs (text -> uuid, text -> integer) still fail, with Postgres' reason: foreign key constraint "pr_id_fkey" cannot be implemented: key columns "id" and "id" are of incompatible types: text and uuid (was Foreign key column type mismatch).

search_path

• SHOW search_path / current_setting('search_path') were "unrecognized configuration parameter"; they return Postgres' default "$user", public. SET search_path TO public, extensions / TO DEFAULT read back as Postgres prints them (SET with a list value used to be ignored).
• Name resolution is unchanged (display only).

Checks

• bun test: 1355 pass, 0 fail (new cases in corpus-parity.spec.ts)
• rapidnative-website, against this build: all 34 CI suites pass, including the live agent scenarios

Known, not changed: SET a.b = ... (dotted custom setting names) does not parse — parser; set_config() works.

Version 4.0.5.

🤖 Generated with Claude Code