`session_store_sql` silently returns empty when session sync is set to local

### Describe the bug

When `sessionSync.level = "local"` (user chose "Keep on this device only"), the `session_store_sql` tool is still injected into every agent's system message and remains callable — but returns 0 rows for all tables. There is no indication to agents that the cloud store is empty *because sync is disabled* — agents can't distinguish this from a user who genuinely has no session history.

The local `~/.copilot/session-store.db` has all the data (600+ sessions, 5,000+ turns), but the system message directs agents to use `session_store_sql` for session history queries, so they conclude there's no history.

### Steps to reproduce

1. Select "Keep on this device only" when prompted for session storage (config: `sessionSync: [{ origin: "*", level: "local" }]`)
2. Use the CLI — sessions accumulate in `~/.copilot/session-store.db`
3. In any session, ask "what did I work on this week?" or have an agent query `session_store_sql`
4. Agent gets 0 results and reports no session history

### Expected behavior

When cloud sync is disabled, one of:

1. **Don't expose `session_store_sql`** — if the cloud store won't have data, don't offer the tool
2. **Have `session_store_sql` query the local DB** — the schemas are compatible (`sessions`, `turns`, `checkpoints`, `session_files`, `session_refs` exist in both)
3. **At minimum, annotate the tool description** so agents know the cloud store won't have data when sync is disabled, and can fall back to the local DB

The above are suggestions — the team likely has better ideas for the right approach given the broader session storage architecture.

### Actual behavior

- `session_store_sql` is injected unconditionally with no awareness of the `sessionSync` config
- Returns 0 rows for all queries — agents can't distinguish "no sessions" from "sync disabled"
- The system message actively encourages agents to use this tool for temporal queries ("what did I work on?", "find prior sessions", etc.)

### Impact

- Automated agents (maintenance tasks, briefings, session digests) that query `session_store_sql` silently get wrong results
- The `/chronicle` feature and any built-in session history features are effectively broken for local-only users
- No error or warning — just empty results that look like valid "no data" responses

### Environment

- Copilot CLI: 1.0.24
- OS: Windows 11
- Config: `sessionSync: [{ origin: "*", level: "local" }]`
- Local session-store.db: 105 MB, 613 sessions, 5,342 turns (healthy)
- Cloud session store: 0 rows across all tables

### Workaround

Query `~/.copilot/session-store.db` directly via Python/sqlite3. The schema is compatible. This requires every consumer of session data to implement fallback logic.

Start at the session_store_sql injection path and the sessionSync configuration handling, then inspect ~/.copilot/session-store.db alongside the cloud-store schema named in the report. Compare local-only behavior with the cloud tool and decide which supported fallback or warning fits the session-storage architecture. Done means local-only users no longer receive misleading empty history results.

Written by the indexing model from the issue text.