[Bug] Copilot never finishes starting: language server blocked on auth.db (SQLite WAL never checkpointed)

AuthStatusManager.signInInitiate()、LanguageServerWrapper.execute()、CopilotUi$1 から始め、次に language server が auth.db を開き、同時実行される reader をどのように処理するかを調査します。報告されている WAL と NFS の条件で起動がブロックされる状態を再現し、issue に記載されている timeout、checkpoint、journal-mode の各オプションを比較します。完了条件は、認証情報へのアクセスによって plugin の有効化が無期限にブロックされず、下流の UI 機能が引き続き使用できることです。

Environment

• OS: RHEL 9 (x86_64), $XDG_CONFIG_HOME on an NFS mount
• Eclipse Version: 4.38, Java 25
• Plugin Version: 0.20.0.202607100822 (copilot-language-server 1.509.5)

Describe the bug

Copilot stopped working completely — chat stuck on "initializing", no status bar icon,
MCP servers never started. Took a while to track down: the language server was blocked
reading $XDG_CONFIG_HOME/github-copilot/auth.db.

That file is SQLite in WAL mode, and on this machine the WAL hadn't been checkpointed
for about two and a half months:

auth.db        4096 bytes   (mtime ~2.5 months old)
auth.db-wal  840512 bytes   (mtime today)
auth.db-shm   32768 bytes   (mtime today)

lsof showed three language servers holding read locks on it at the same time, and at
some points twelve had been running concurrently:

copilot-l <pid1> 19ur .../github-copilot/auth.db
copilot-l <pid2> 19ur .../github-copilot/auth.db
copilot-l <pid3> 19ur .../github-copilot/auth.db

On the server side the symptom is that it starts, logs initialized, then goes
completely quiet — 0 seconds of CPU time, no network connections, nothing more in the
log. On the client side every request queues behind LanguageServerWrapper.execute() and
never returns:

"Worker-N: Copilot initialization"  WAITING (parking)
    java.util.concurrent.CompletableFuture.get()
    at com.microsoft.copilot.eclipse.ui.CopilotUi$1.run(CopilotUi.java:101)

"Worker-M: Initializing GitHub Copilot sign-in process..."  WAITING (parking)
    at com.microsoft.copilot.eclipse.core.AuthStatusManager.signInInitiate(AuthStatusManager.java:59)
    at com.microsoft.copilot.eclipse.ui.handlers.SignInHandler$SignInJob.initiateSignIn(SignInHandler.java:96)

Since chatServiceManager is only assigned after that job finishes, everything downstream
goes with it. Chat never initializes, the status bar item is never created, MCP is never
started, and opening the MCP preference page throws

NullPointerException: ...CopilotUi.getChatServiceManager() is null
    at McpPreferencePage.createExtMcpRegistrationArea(McpPreferencePage.java:389)
    at McpPreferencePage.createFieldEditors(McpPreferencePage.java:232)

which leaves a half-drawn page and a "page contains invalid values" dialog.

Signing in is not a workaround — signInInitiate() blocks the same way, so each attempt
just adds another stuck job. I ended up with 15 of them.

To Reproduce

Hard to trigger on demand, it builds up over time. What it seems to need:

1. $XDG_CONFIG_HOME on a network filesystem (NFS here).
2. Several language servers alive at once with overlapping lifetimes — easy if they
   leak, see the other issue.
3. Over weeks the WAL grows, because passive checkpoints can never get past the
   readers. At some point startup blocks for good.

Expected behavior

Reading credentials shouldn't be able to block plugin activation forever, and the WAL
shouldn't grow unbounded without anyone noticing.

Additional context

The fix turned out to be trivial once I found it. With every language server stopped,
just opening the database was enough:

$ sqlite3 auth.db "PRAGMA integrity_check;"            -> ok
  (auth.db went 4096 -> 45056 bytes, -wal and -shm disappeared)
$ sqlite3 auth.db "PRAGMA wal_checkpoint(TRUNCATE);"   -> 0|0|0
$ sqlite3 auth.db "PRAGMA integrity_check;"            -> ok

Nothing was lost, the stored credential was intact, and Copilot authenticated on its own
2.5 s after the next restart. So the only thing blocking the checkpoint all along was the
concurrent readers.

Two things I noticed while digging:

• The SQLite docs say WAL isn't supported on network filesystems, because the -shm index
  relies on shared memory mapping. Even on a single host though, a continuous chain of
  overlapping readers is enough to starve passive checkpoints.
• copilot-eclipse.db lives in the same directory and uses journal_mode=delete. It was
  never affected.

Would you consider journal_mode=DELETE for auth.db, or at least detecting a networked
config directory? A timeout on the credential read would help a lot too — CopilotUi$1
currently calls CompletableFuture.get() with no timeout, so any stall there takes down
the entire plugin UI including the sign-in entry point. #370 looks like the same class of
problem, a request that never resolves permanently disabling things.