Autocomplete suggestions vanish after typing '.' on schema-qualified table names

[openidle-dev]

Repro

1. Connect to a Postgres DB that has tables outside the public schema (e.g. an app.users table).
2. In a SQL tab type: SELECT * FROM app
3. Observe: autocomplete lists app.users, app.products, etc. ✓
4. Type .
5. Observe: all suggestions disappear. The list collapses to empty.

Expected

After typing app., the autocomplete should narrow to app.users, app.products, etc. — the schema-qualified tables under the app schema. (Or alternatively, drop the app. prefix and show users, products — both are reasonable.)

What's actually happening

src/components/editor/QueryEditor.tsx lines 738-754 (the completion provider) DO extend the range back across the dot when computing the replacement range, so the provider returns the full app.users-style labels with range covering app.. That part is correct.

The breakdown looks like Monaco's default fuzzy matcher: when the cursor is right after a ., Monaco appears to apply member-access semantics — it expects each suggestion to have a label representing the member (e.g. users), not the full path (app.users). Labels that contain a . early in the string get filtered out.

This is consistent with how Monaco treats . in other language modes (TS, JS) where obj. shows methods/properties of obj, with bare property names as labels.

Suggested fix sketch

Two approaches, either works:

1. Detect the schema-prefix context and return bare labels with a smaller range. In the provider, if the char preceding startColumn is ., extract the schema name to the left, filter items.tables to only entries starting with <schema>., and return them with the table name only as the label and the range covering only the text after the dot.

2. Override Monaco's filter. Set filterText explicitly on each suggestion to a value Monaco's fuzzy matcher will accept after a dot. Less clean.

Approach #1 matches how DataGrip and DBeaver handle this and is the more user-friendly behaviour.

Scope

Pre-existing bug. Not introduced by today's PRs (#22, #23, #25). Discovered while smoke-testing PR #22's schema cache reset on disconnect — the data path is correct (schema items load with app.users-style entries), the rendering filter is what breaks.

Workaround

Type the full table name without the schema prefix (SELECT * FROM users) — autocomplete suggests app.users and resolves correctly once selected. Or type app.users manually without relying on completion.

[openidle-dev]

Scope expanded during fix

While testing the schema-dot fix against the dev test DB, the same root cause was found to also break alias.column completion on multi-dot lines:

SELECT u.id FROM app.users u WHERE u.

After typing u., the column list collapses to empty. Two compounding issues in the pre-existing else if (tablePrefix) branch in QueryEditor.tsx:

1. tablePrefix is extracted via lineContentAfterDot.lastIndexOf('.'), which on a line that already contains app.users returns the wrong dot — so tablePrefix ends up as "app" instead of "u", and alias resolution silently fails.
2. Even with the correct alias, Monaco's dot-trigger filter eats bare column labels exactly the same way it ate schema.table labels — the range covers u. and Monaco applies member-access semantics.

Both <schema>.<typed> and <alias>.<typed> (and <table>.<typed> where the table is referenced without an alias) are now handled by the same dedicated completion pathway extracted to src/components/editor/completionContext.ts. The old tablePrefix branch is removed.