Fix MCP OAuth Connect permission gating

[NianJiuZst]

Summary

• derive an explicit MCP OAuth canConnect permission from the workspace owner/admin role
• disable OAuth Connect actions for members and viewers on both directory cards and details
• guard the popup handler itself and add admin/member/viewer Playwright coverage

Root cause and impact

The MCP directory UI distinguished import permission, which includes members, but did not model the narrower OAuth connection permission. Every disconnected OAuth connector therefore rendered an active Connect action even though the backend OAuth start and callback routes authorize only workspace owners and admins. Members and viewers could open a popup that was guaranteed to receive a 403 and never complete the parent-page flow.

The UI now uses the same owner/admin boundary as the backend. Members can still import an OAuth connector after an administrator has connected it, while unauthorized users no longer receive a misleading active Connect action.

Validation

• pnpm exec playwright test --config tests/e2e/playwright.config.ts tests/e2e/mcp-directory.spec.ts --grep "MCP OAuth" (3 passed)
• pnpm --filter @parsar/web typecheck
• ESLint on the changed MCP directory components
• go test ./server/internal/api/mcpdirectory -run '^TestOAuthConnectRequiresWorkspaceAdmin$' -count=1
• make check

make check passed. Docker was unavailable locally, so the PostgreSQL migration smoke test was skipped; this change does not touch database code or migrations.

The full mcp-directory.spec.ts still hits an unrelated pre-existing Skill-tab mock failure at the Diagram Maker assertion. The same failure was reproduced on the unmodified main baseline at 90146d4; all OAuth-focused cases pass.