WorkIQ MCP tools never exposed to session processes despite successful app-level OAuth

### Short summary

The WorkIQ MCP server authenticates successfully at the app/daemon level (UI shows a green checkmark after a brief sign-in prompt on restart), and a valid OAuth access token is cached to disk. However, individual project/chat sessions spawn their own child processes for MCP client connections, and those child processes report "no cached tokens" for WorkIQ and never expose any workiq-* tools — even though the token cache file exists and is valid at the time.

### Affected version or release

v1.0.22

### Installation context

_No response_

### What happened?

# Bug: WorkIQ MCP tools never exposed to session processes despite successful app-level OAuth

## Summary
The WorkIQ MCP server authenticates successfully at the app/daemon level (UI shows a
green checkmark after a brief sign-in prompt on restart), and a valid OAuth access
token is cached to disk. However, individual project/chat sessions spawn their own
child processes for MCP client connections, and those child processes report
"no cached tokens" for WorkIQ and never expose any `workiq-*` tools — even though the
token cache file exists and is valid at the time.

## Environment
- Copilot CLI desktop app (Windows)
- Config file: `%USERPROFILE%\.copilot\mcp-config.json`
- WorkIQ plugin: `copilot-plugins/workiq`, version 2.0.0, enabled: true
- WorkIQ MCP entry (added manually to mirror official microsoft/work-iq repo config):
```json
"workiq": {
"tools": ["*"],
"type": "http",
"url": "https://workiq.svc.cloud.microsoft/mcp",
"oauthClientId": "",
"oauthPublicClient": true,
"auth": { "redirectPort": 12798 }
}
```

## Steps to Reproduce
1. Ensure `workiq` entry exists in `mcp-config.json` as above.
2. Restart the app. Observe a brief sign-in button/prompt that resolves to a green
checkmark (indicating WorkIQ connected at the app level).
3. Open any new project session or chat session.
4. Ask the session to scan its available tools for a `workiq-` prefix
(e.g. `workiq-ask`, `workiq-fetch`, `workiq-search_paths`, `workiq-get_schema`,
`workiq-create_entity`, `workiq-update_entity`, `workiq-delete_entity`,
`workiq-do_action`, `workiq-call_function`).

## Expected Result
The new session's tool list includes the `workiq-*` MCP tools, since the app already
shows WorkIQ as connected/authenticated.

## Actual Result
No `workiq-*` tools appear in any freshly created session — tested across 4+ separate
sessions, both project sessions and quick chats, after multiple full app restarts.
Only the unrelated `workiq` documentation *skill* (not an MCP tool) is present.

## Evidence from logs (`%USERPROFILE%\.copilot\logs\process-*.log`)

Every session process log shows the same pattern within ~200ms of startup:
```
[ERROR] Starting remote MCP client for workiq with url: https://workiq.svc.cloud.microsoft/mcp
[ERROR] Connecting MCP client for workiq...
[ERROR] [rust:rmcp::transport::worker] worker quit with fatal: Transport channel closed,
when AuthRequired(AuthRequiredError { ... })
[ERROR] Server workiq requires authentication, initiating OAuth flow
[ERROR] OAuth authentication required for workiq
[ERROR] OAuth required for workiq with no cached tokens; marking as needs-auth
```

However, the OAuth token cache file
`%USERPROFILE%\.copilot\mcp-oauth-config\.tokens.json` DOES contain a valid
`accessToken` for `serverUrl: https://workiq.svc.cloud.microsoft/mcp`,
`clientId: ` at the same time these "no cached
tokens" errors are being logged by new session processes.

Separately, `github-app..log` shows the app's own daemon successfully completing
an OAuth callback and reconnecting WorkIQ via cached tokens:
```
mcp_status: MCP OAuth non-first-party server; cancelling host-token and kicking
daemon-owned reconnect so the status badge can resolve server_name=workiq
mcp_status: third-party MCP server reconnected via cached OAuth tokens server_name=workiq
```
And one session process log (`process--.log`) shows a genuinely
successful connection with full tool capability:
```
Service initialized as client { ... server_info: Implementation { name: "WorkIQ.MCP.Server",
version: "1.0.45.0" }, capabilities: { tools: Some(ToolsCapability { list_changed: Some(true) }) } }
MCP client for workiq connected, took 2406ms
```
...but this connection was torn down ~70 seconds later when that session/process
was cancelled, and the tool list for that session had apparently already been
finalized before the reconnect completed — so the tools were never actually
surfaced to the model.

## Root Cause Hypothesis
Each session appears to spawn an independent process for its MCP client connections
rather than sharing the app daemon's already-authenticated WorkIQ MCP connection/token
cache. The per-process OAuth check races against (and loses to) the async daemon-level
reconnect, so the session's tool list is built before a valid token can be attached,
and the session falls back to "needs-auth" with tools never populated. Non-OAuth /
first-party MCP servers (context7, nuget, desktop-commander, azure-devops) are
unaffected because they don't require this handshake.

## Impact
WorkIQ (and potentially any other OAuth-based third-party MCP server) is unusable in
any session despite the app reporting it as connected — the green-checkmark status
is misleading since it does not reflect per-session tool availability.

### Steps to reproduce

## Steps to Reproduce
1. Ensure `workiq` entry exists in `mcp-config.json` as above.
2. Restart the app. Observe a brief sign-in button/prompt that resolves to a green
checkmark (indicating WorkIQ connected at the app level).
3. Open any new project session or chat session.
4. Ask the session to scan its available tools for a `workiq-` prefix
(e.g. `workiq-ask`, `workiq-fetch`, `workiq-search_paths`, `workiq-get_schema`,
`workiq-create_entity`, `workiq-update_entity`, `workiq-delete_entity`,
`workiq-do_action`, `workiq-call_function`).

### Expected behavior

## Expected Result
The new session's tool list includes the `workiq-*` MCP tools, since the app already
shows WorkIQ as connected/authenticated.

## Actual Result
No `workiq-*` tools appear in any freshly created session — tested across 4+ separate
sessions, both project sessions and quick chats, after multiple full app restarts.
Only the unrelated `workiq` documentation *skill* (not an MCP tool) is present.

### Additional context

_No response_