Summary

The GitHub Copilot SDK migrated its OAuth token storage from JSON files (apps.json / hosts.json) to a SQLite database (auth.db) under the same github-copilot config directory. Zed only knew about the JSON files, so users on a fresh SDK install saw an empty Copilot Chat model dropdown even though they were signed in via the LSP (edit predictions worked fine, since those go through the LSP directly).

This PR teaches copilot_chat to read auth.db, and replaces the previous filesystem watcher with an LSP-driven reload triggered by didChangeStatus from the copilot crate.

Related: #57219 (same user-visible symptom; different root cause from #57738 — both fixes are needed depending on which SDK build the user has).

Changes

• extract_oauth_token_from_db() reads token_ciphertext from the oauth_tokens table via the existing sqlez dependency. The column stores the raw ghu_... OAuth token as text on current SDK builds. Format is validated (prefix + length ≥ 36 + ASCII alphanumeric/underscore) so we fail closed if the SDK changes the schema again.
• CopilotChat::reload_auth(cx) is a small public method that re-reads the token. On sign-out it also clears api_endpoint and models so a subsequent sign-in re-discovers them rather than reusing stale state.
• notify_copilot_chat_auth_changed() in copilot.rs calls reload_auth whenever update_sign_in_status would emit CopilotAuthSignedIn / CopilotAuthSignedOut. The copilot crate already depends on copilot_chat, so this is the clean direction of the cross-crate poke.
• Removed the previous fs.watch() loop on the config directory.

Why not just keep the filesystem watcher?

It was flaky on Windows specifically because of how SQLite finalises writes:

• The WAL is written alongside the main file and finalised with rename/replace; some commits surfaced as multiple watcher events, others as none.
• The watcher sometimes fired before the new token row was committed — we read None, then the LSP told us we were signed in.
• A 100 ms debounce papered over the symptom but not the cause.

Why not sqlite3_update_hook / commit_hook?

Investigated and rejected. SQLite update/commit hooks are per-connection, in-process callbacks: they fire only when your own connection writes the DB. They're not an IPC mechanism. The Copilot LSP writes auth.db from a different process — our connection would never see those writes regardless of how many hooks we register. SQLite has no LISTEN/NOTIFY equivalent; that's a deliberate library-not-server design choice.

Why the LSP signal?

The Copilot LSP already has the ground-truth event — didChangeStatus. It's the same notification VS Code's Copilot extension subscribes to internally. Tapping the producer's semantic signal beats watching its incidental filesystem side-effects: it works the same way on Windows / macOS / Linux, and it fires after the token is durably written.

Testing

Tested on Windows 11 with the official Copilot SDK build that ships auth.db:

• Cold sign-in: model dropdown populates within a couple of seconds of the LSP reporting Authorized, no restart needed.
• Sign-out: model list clears; subsequent sign-in re-fetches endpoint + models.
• Legacy apps.json / hosts.json users: unaffected (JSON path is tried first).

Notes for reviewers

• The token-format check (ghu_ prefix, length ≥ 36, ASCII alnum/_) is intentional defence-in-depth in case the SDK eventually starts storing actually-ciphertext in token_ciphertext. If that happens, we log a warning and return None rather than passing garbage to the API.
• No new dependencies — sqlez is already a workspace member.

Release Notes:

• Fixed GitHub Copilot Chat showing an empty model dropdown for users on newer Copilot SDK builds that store the OAuth token in auth.db instead of apps.json/hosts.json, and made the model list refresh automatically after signing in or out without requiring a restart.