MCP advertises fetch but tools/call returns Unknown tool after EULA acceptance

Reproduction\n\nOn macOS arm64 with @microsoft/workiq@1.0.0 (1.0.0.28144+10c4074):\n\n1. workiq auth login succeeds for an organizational account.\n2. workiq auth consent reports consent granted.\n3. workiq config show reports I-accept-EULA=true.\n4. Start workiq mcp, initialize MCP protocol 2025-03-26, and send notifications/initialized.\n5. tools/list includes a tool named fetch.\n6. tools/call with name: fetch and {"entityUrls":["/me?$select=id,displayName"],"agentId":null} returns JSON-RPC -32602 Unknown tool: fetch.\n7. Calling the advertised accept_eula tool first succeeds with “full access”, but a subsequent fetch call still does not succeed.\n8. The standalone workiq fetch command hangs in broker acquisition and can generate repeated SSO windows despite successful login/consent.\n\nThe same failure occurs both with an explicit --account and while inheriting defaultAccount. This blocks deterministic background Outlook/Teams collection. Expected: every tool returned by tools/list, especially fetch, is callable after initialization and saved EULA/auth consent is inherited without repeated interactive prompts.

Start by reproducing the workiq mcp sequence through initialization, tools/list, accept_eula, and tools/call for fetch. Trace how the advertised fetch tool is dispatched and how saved auth consent is inherited, then verify that fetch is callable after initialization without repeated SSO prompts or broker hangs.