Feature: expose source_tables on Query proto for plugin access to full query table dependencies

[lumosminima]

What do you want to change?

Problem

Plugins receive Query.columns[].table which only covers tables contributing
to SELECT output. Tables referenced only in subqueries, CTEs, or JOINs are
invisible to plugins.

Example — plugin only sees accounts, misses account_tags and transactions:

-- name: ListSpaceAccounts :many
WITH filtered_accounts AS (
    SELECT account_id FROM accounts WHERE space_id = ?
    AND NOT EXISTS (
        SELECT 1 FROM account_tags t WHERE t.account_id = accounts.account_id
    )
)
SELECT acc.* FROM accounts acc
JOIN filtered_accounts fa ON acc.account_id = fa.account_id
LEFT JOIN transactions t ON t.debit_account_id = acc.account_id

Use case

SQLite's update_hook fires with the name of the written table. Frontend plugins
generating reactive query stores need every table a query depends on — not just
output columns — to know when to refetch. Currently the only workaround is running
sqlc parse as a separate post-codegen script outside the plugin WASM sandbox.

Proposed change

Add source_tables to the Query proto:

message Query {
  // ... existing fields ...
  repeated string source_tables = 7; // all tables this query reads from, CTEs excluded
}

sqlc's analyzer already resolves this internally when validating joins and column
references — this only surfaces existing data through the proto, no new analysis needed.

Expected result

source_tables: ["account_tags", "accounts", "transactions"]

Alternatives considered

Approach	Problem
Regex on Query.text inside plugin	Fragile, false positives
sqlc parse as post-codegen script	Can't run from inside WASM sandbox
Column.table from output columns	Misses subquery/CTE/JOIN-only dependencies

What database engines need to be changed?

No response

What programming language backends need to be changed?

No response