Summary

Activates the omni-side fixes for the seven audited Trino under-masking vectors (BYT-9674..BYT-9680, sub-issues of BYT-9142). Columns reaching a sensitive base column through indirection — derived tables, CTEs, UNNEST, scalar subqueries, set-operation arms, views, and SELECT * over derived relations — previously had empty or width-wrong lineage, so the positional result masker fell through to NoneMasker (or slid) and returned values unmasked.

-- masking policy on customer.phone — ALL of these previously leaked:
SELECT d.x FROM (SELECT phone AS x FROM customer) d;
WITH w AS (SELECT phone AS pp FROM customer) SELECT pp FROM w;
SELECT (SELECT phone FROM customer LIMIT 1) AS sp FROM customer;
SELECT name FROM customer UNION SELECT phone FROM customer;
SELECT * FROM (SELECT phone, name FROM customer) d;   -- positional slide
SELECT phone FROM customer_v;                          -- view
SELECT t.p FROM customer CROSS JOIN UNNEST(phones) AS t(p);

Changes

• Bump github.com/bytebase/omni to v0.0.0-20260610061900 — pulls fix(trino/analysis): deepen masking lineage through derived tables, CTEs, UNNEST, scalar subqueries, and set operations omni#286 (additive lineage resolver), feat: added env-guide #296 (provably-width-correct star expansion), feat(tenancy): create database using schema from existing tenant when a project is in tenant mode #295 (catalog-aware view lineage).
• Query-span extractor now calls analysis.GetQuerySpanWithCatalog with a catalog built from instance metadata: views carry their defining query (lineage through a view reaches the base-table columns masking config attaches to); tables carry their column lists (SELECT * expands to the exact projection — positional masker stays aligned). Catalogs load lazily and transitively (a view definition referencing another catalog pulls it in, so cross-catalog views resolve); metadata fetches reuse the extractor's cache.
• completion.go fills catalog.View.Definition (shared catalog model).
• IsPlainField keys on the mapped physical source set (the additive resolver restates a plain column as written + qualified refs).

Safety model

omni resolution is additive (written refs always retained → masking only broadens) and stars expand only when provably width/order-correct — anything uncertain (stale metadata, USING/NATURAL coalescing, unknown relations) stays opaque and this extractor's existing metadata expansion applies as before. With no metadata available, omni behaves byte-identically to the previous catalog-less call.

Verification

• 7 consumer-level audit regression tests (query_span_lineage_test.go) — one per leak vector, including the SELECT *-over-derived repro pinned at exact width/order.
• 9 view-lineage tests (query_span_view_test.go) — carried from the superseded fix(parser/trino): resolve view-column lineage to base tables for masking (BYT-9679) #20560, plus a new cross-catalog view test.
• Full plugin/parser/trino, plugin/schema/trino, api/v1 suites green; gofmt clean.

Cross-review

Every layer of this work was adversarially reviewed by an independent agent (Codex) in a find→fix→re-verify loop — the omni PRs (#286/#296/#295) each went through it, and this wiring patch did too: it surfaced the cross-catalog view gap (fixed via transitive catalog loading + regression test) and confirmed the USING-join residual analysis below.

Notes for review

1. Access-control visibility change: omni now surfaces a view definition's base tables in AccessTables, so access checks also consider tables read through views. Flagging for product judgment.
2. Pre-existing residual (unchanged): the USING/NATURAL-join opaque-star positional trap predates this PR; the newly-appended view-def tables land at the end of AccessTables, beyond the executed result width, so they are never indexed by the masker — verified independently in review.

🤖 Generated with Claude Code