feat(prover): SaaS connector permission modeling — Slack, Discord, Telegram

[zredlined]

Problem Statement

OPP currently models binary capabilities and GitHub API/credential scopes. Real-world sandbox deployments connect to SaaS platforms like Slack, Discord, and Telegram where the security-relevant question is not just "can traffic reach this host" but "what can the bot actually do once connected."

For example, a Slack bot with chat:write and channels:read scopes can post messages and read history, but cannot upload files, read DMs, or manage the workspace. OPP should be able to reason about these distinctions and flag when policy + credentials allow more than intended.

Proposed Design

Add API descriptor and credential registry files for each connector, following the existing pattern in crates/openshell-prover/registry/:

Slack (apis/slack.yaml, credentials/slack-bot-token.yaml):

• Model OAuth scopes → allowed API actions (e.g., chat:write → POST to chat.postMessage)
• Distinguish read-only scopes (channels:read, app_mentions:read) from write scopes (files:write, admin.*)
• Model WebSocket endpoints (wss-primary.slack.com) as event-receive-only

Discord (apis/discord.yaml, credentials/discord-bot-token.yaml):

• Model bot permissions bitmask → allowed actions
• Distinguish message send from file upload, channel management, DM access

Telegram (apis/telegram.yaml, credentials/telegram-bot-token.yaml):

• Model Bot API methods → read vs write actions
• Distinguish sendMessage from sendDocument, getFile, admin operations

Verification queries

With this data, OPP's existing exfiltration and write-bypass queries would automatically cover these endpoints. Additionally:

• "Can this bot upload files to Slack?" (exfil via files.upload)
• "Can the agent read DMs?" (scope + endpoint reachability)
• "Can data from GitHub reach Telegram?" (cross-endpoint exfil path)

Alternatives Considered

1. Generic REST modeling only — Mark endpoints as L7 with method/path rules. This catches HTTP-level issues but misses scope semantics (e.g., a POST to chat.postMessage is allowed by scope but a POST to files.upload is not, even though both are POST requests to api.slack.com).

2. Per-deployment custom registry — Let users define their own API models. Too much burden on users; the common connectors should ship with the prover.

Agent Investigation

• Current registry structure: crates/openshell-prover/registry/{binaries,apis,credentials}/
• GitHub is the only API with a descriptor today (apis/github.yaml)
• The credentials.rs loader already supports scope-to-action mapping
• Slack, Discord, and Telegram are among the most common endpoints in real deployments (see social-monitoring thread)

Context

Tracks under #781 (OPP roadmap). Motivated by the social-monitoring deployment review where Slack/Discord/Telegram policy verification was needed.

[zredlined]

Moved to Linear for roadmap tracking.