Pro activation power step re-sells MCP setup to users who already connected a client

Found during review of #5607 (PR: `fix/pro-activation-mcp-deeplink-5607`). Pre-existing behavior, sharpened by that change.

The activation wizard decides whether the power step is already satisfied with:

```ts
// src/components/ProActivationInterstitial.ts — hasUsedPowerFeature()
return loadWidgets().length > 0;
```

Only locally-stored custom widgets count. Server-side MCP client rows (`convex/mcpProTokens.ts`, surfaced by `listMcpClients()` in `src/services/mcp-clients.ts`) are never consulted.

So a Pro subscriber who has already connected Claude Desktop or Cursor still sees the power step presented as unfinished work. #5607 changed that step's pointer copy from "Get your API & MCP keys" to the more directly imperative "Set up MCP", which makes the mismatch more noticeable — the card now asserts a specific task the user may have completed weeks ago.

Options:
- Fold connected MCP clients into the signal: add a bounded `listMcpClients()` probe to `readActivationContextStrict` (which already awaits a network read) and OR a non-empty, non-revoked client list into `config.hasUsedPowerFeature`, keeping the widget check as the synchronous fallback in `readActivationContext`.
- If the extra round trip isn't worth it, soften the label to non-imperative phrasing so it doesn't assert an unfinished task.

Needs a product call on whether the round trip is acceptable, hence not fixed in #5607.

Start with hasUsedPowerFeature() in src/components/ProActivationInterstitial.ts and trace readActivationContextStrict/readActivationContext. Inspect listMcpClients() in src/services/mcp-clients.ts and convex/mcpProTokens.ts, then resolve whether the network read is acceptable or the label should be softened. Done means previously connected, non-revoked MCP clients no longer see an incorrectly unfinished power step, or the wording no longer asserts that task.

Written by the indexing model from the issue text.