Improve schema search_path handling (overwrite → append/prepend)

[aesslinger]

Migrated from tabularis#653. Part of the Phase 2 set of PostgreSQL-specific features beyond the built-in driver.

Problem

Selecting a schema in the UI sets search_path by overwriting it to just that one schema (SET search_path TO "<schema>" — see src/handlers/query.rs's exec_query/schema-setting logic), rather than prepending/appending it onto the connection's actual configured search_path. This breaks queries against objects that live in a different schema than the one currently selected: the user has to manually run SET search_path TO public, analyst; select * from whatever; as a workaround, split across two tabs.

Original report (tabularis#653):

tabularis should query the search path on a new connection and then use that, with the selected schema appended on the end. Maybe Ideally there would be a way to define or override that behaviour with a connection specific search_path rather than the one defined in postgresql.conf

Proposed approach

• On connect, query the server's actual configured search_path (SHOW search_path or current_setting('search_path')) instead of assuming it's unset.
• When a schema is selected in the UI, append it to (or prepend, matching Postgres's own resolution order) the connection's real search_path rather than replacing it outright.
• Consider a per-connection search_path override setting (distinct from the schema selector) for users who want to permanently set an environment across sessions, per the original request.

Notes

• This same overwrite behavior exists in the built-in driver too (tabularis's drivers/postgres/mod.rs's acquire_pg_client), so this isn't a plugin-specific regression — but since this plugin's handlers::query::exec_query owns the fix location now, and the built-in driver is on a deprecation path (this plugin is intended to supersede it), doing it here is the right call.
• Overlaps conceptually with the general "schema handling" scope tracked in Phase 2: PostgreSQL-specific features beyond the built-in driver (tabularis#16) #9/fix: declare a branded icon so the plugin doesn't show the generic fallback #16 but isn't currently covered by an existing Phase 2 sub-issue (Phase 2.1: Sequence management #25–Phase 2.8: Wire up stubbed batch/snapshot RPC methods #32).

[aesslinger]

---

Additional context (both call sites confirmed identical):

Both exec_query (src/handlers/query.rs:134-135) and execute_query_batch (src/handlers/query.rs:56-57) independently run the exact same overwrite:

let set_path = format!("SET search_path TO \"{}\"", s.replace('"', "\"\""));

right after acquiring the pooled client, with no prior read of the connection's existing search_path. Any fix needs to update both call sites (or factor them into one helper first — they're already duplicated verbatim, which is itself worth fixing while touching this code).

One nuance for the fix: because pools are cached and reused (client.rs's connection_key), a naive "read current search_path, then append" on every acquire would need to either (a) read-and-restore before each query if pooled connections might have a stale appended path from a previous caller's schema selection, or (b) compute the target search_path string once per request from <connection's base search_path> + selected schema rather than mutating the live session state incrementally. Worth deciding which model before implementing, since pooled connections are shared across calls with potentially different schema params.