MCP servers reported as "blocked by policy" on first launch when using a custom config directory

### Describe the bug

When launching Copilot CLI with a non-default config directory, MCP servers are incorrectly reported as "blocked by policy". Sending one message and restarting (/restart) fixes it for that session.

### Affected version

1.0.20

### Steps to reproduce the behavior

1. Launch Copilot CLI with a non-default config directory (e.g. via env var pointing to a custom ~/.copilot-/ folder)
2. Observe that MCP servers are reported as blocked by policy immediately on startup
3. Send one message, then /restart
4. MCP servers now load correctly

### Expected behavior

MCP servers load on first launch.

### Additional context

Root cause hypothesis: The custom config dir has no session-store.db, so there is no cached policy state. The CLI appears to have a race condition where MCP initialization completes
before the async enterprise policy fetch from the GHE host finishes — defaulting to "blocked" instead of waiting for the result.

Workaround: One message + /restart resolves it for that session.

Start by reproducing the first-launch flow with a non-default config directory and trace MCP initialization alongside the asynchronous enterprise policy fetch from the GHE host. Done means MCP servers load correctly on the initial launch without requiring a message and /restart, with regression coverage for a missing session-store.db.

Written by the indexing model from the issue text.