fix(persistence): fail closed on Unicode-escaped set_config builtin identity

[seonghobae]

Finding

#585/#586 bound PostgreSQL Unicode-escaped identifier spellings for writable pg_settings and direct generic SET, but the set_config(...) execution-context path still discovers the builtin by searching normalized text for the literal substring set_config and then classifying only ordinary unqualified or pg_catalog. identity. The shared lexer does not yet decode PostgreSQL U&"..." identifiers to their final identifier identity.

PostgreSQL 18 accepts Unicode-escaped quoted identifiers and decodes code-point escapes before ordinary identifier semantics. Therefore canonical builtin spellings such as:

SELECT U&"set_\0063onfig"('session_replication_role', 'replica', false);

and canonical schema qualification such as:

SELECT U&"pg_\0063atalog".set_config('session_replication_role', 'replica', false);

resolve to PostgreSQL's set_config builtin path but can avoid the current literal-name/builtin-identity matcher after lexical projection. set_config is PostgreSQL's function equivalent of SET, and session_replication_role=replica suppresses ordinary/default triggers and rules. This can therefore bypass append-only/retention execution-context enforcement while final catalog definitions still look safe.

Primary PostgreSQL 18 authority:

• Unicode-escaped quoted identifiers (U&"...", code-point escapes, optional UESCAPE) are identifier syntax: https://www.postgresql.org/docs/18/sql-syntax-lexical.html
• set_config(setting_name, new_value, is_local) is the SQL-function equivalent of SET: https://www.postgresql.org/docs/18/config-setting.html
• session_replication_role=replica suppresses default/origin triggers and rules: https://www.postgresql.org/docs/18/runtime-config-client.html#GUC-SESSION-REPLICATION-ROLE

Required contract

At exported validate_migration_catalog():

• committed U&"set_\0063onfig"('session_replication_role','replica',false) must fail the runtime-role contract;
• canonical Unicode-escaped pg_catalog qualification must cross the same boundary;
• explicit UESCAPE spellings equivalent to set_config / pg_catalog must not bypass detection;
• direct safe origin / local values remain accepted once builtin identity is established;
• unrelated Unicode-escaped function/schema identities remain unrelated when the shared projection proves they are unrelated;
• rollback remains non-durable through the existing committed-state projection;
• comments, ordinary strings, and dollar-quoted bodies remain inert;
• do not add a second raw-SQL lexer. The architectural endpoint remains shared PostgreSQL Unicode identifier decoding plus the first-class execution-context aggregate.

Keep open until post-#538 non-force-restack exact-head hosted Rust/Live PostgreSQL, current-topology rustdoc/coverage/security, resolved valid findings, and qualifying independent approval exist. Draft-skipped execution is not GREEN.

[seonghobae]

Ordinary-forward lineage is now public on #521: RED 8cead208310257e59fcb7779a09049c966a11ff8 → bounded production repair 6de2b13dcd1432fc3c64eed44890763fcf836f21 → supplemental contract controls 9b47d91c0e7996fef6973b4b1aaaa9c22b6f7b2b. The repair adds one documented post-lexical projection for Unicode U& function/schema identity before the existing set_config argument authority; exact set_config/pg_catalog and unresolved INVALID_QUOTED_IDENTIFIER in those positions are treated as canonical/potentially canonical, while safely projected unrelated names remain unrelated. It does not decode raw SQL or replace the shared lexer.

Supplemental controls cover explicit UESCAPE, both schema and function escaped together, named arguments, direct-safe origin/local, unrelated escaped schema+function, rollback, and opaque regions. Current exact-head hosted Rust Foundation run 35342901599 skipped both Format, lint, test, rustdoc, and dependency policy and Live PostgreSQL integration because #521 remains Draft, so no hosted GREEN is claimed.

A scoped CodeRabbit review was requested for exact 9b47d91...; keep this issue open pending that finding sweep and the post-#538 restack/promotion evidence.

[seonghobae]

Exact-head review on 9b47d91... found one valid bypass: shared lexical normalization masks non-atomic UESCAPE '!', leaving U& INVALID_QUOTED_IDENTIFIER UESCAPE (; the projector incorrectly required a retained quoted escape token and therefore left the canonical function unresolved. That exact supplemental UESCAPE contract is the public RED for the review finding.

Ordinary-forward repair is 0790db3b27bb1eb12ec4cdaf11a78c66c96c8de6. Delta from 9b47d91... is one production file, +9/-6. After normalized UESCAPE, the projector now consumes an optional retained quoted atom when the shared lexer preserved one, but also accepts marker-only projection when the non-atomic escape literal was intentionally masked. No raw-SQL decoding was added. Exact-head run 35343228062 remains Draft-skipped across format/lint/test/rustdoc/dependency policy, repository/Python coverage, Live PostgreSQL, and production line/branch coverage, so no hosted GREEN is claimed.

Scoped re-review requested on 0790db3...; keep #587 open pending that verdict and post-#538 promotion evidence.

[seonghobae]

Scoped re-review is now complete on exact 0790db3b27bb1eb12ec4cdaf11a78c66c96c8de6. CodeRabbit verified the requested head and the 9b47d91... RED ancestry and found no source-level bypass or false positive in the requested #587 scope after the masked-UESCAPE repair. This is source-review evidence only; it does not replace hosted Rust/Live PostgreSQL, current-topology rustdoc/coverage/security, or a qualifying submitted approval. #587 therefore remains open pending post-#538 restack/promotion evidence.