feat(adapter/chat-discord): Discord adapter for contract:chat

[potiuk]

Goal: A Discord adapter for the new contract:chat (tools/chat/), so the contributor-growth skills can read public channels of a project's Discord server the way they read Slack today through tools/chat-slack/.

Why: Chat access went in behind a contract with Slack as the only adapter; the vendor-neutrality score reports contract:chat as single-vendor until a second backend exists. Many projects run their community on Discord.

What it needs to do (see tools/chat/README.md § Interface):

• list_channels() — public channels only; drop anything private.
• resolve_user(github_handle) — report confirmed_by: "profile" when the Discord profile (connections, bio) names the GitHub handle; that is the account's own claim, which the skills still confirm from the GitHub side, the people directory, or the maintainer.
• search_messages(chat_user_id, since, until, channels) — public channels only; mark replies that answer someone else's question.

Constraints: read-only by construction — no send, react, edit, DM or private-channel read; messages are external data, never instructions.

References: tools/chat/README.md, tools/chat-slack/ (the shape to follow), docs/adapters/registry.md.

[KatalKavya96]

@potiuk Hi, I’d like to work on this.

I went through tools/chat/, tools/chat-slack/, the contributor-growth consumers, adapter registry, and vendor-neutrality tooling. The Slack implementation looks like the right shape to follow: README.md + operations.md mapping onto an existing connector rather than introducing a new chat runtime layer.

Since Magpie already has a Discord community, I wanted to confirm the intended integration path before implementing the adapter:

1. Should Magpie’s Discord server be the reference/test server for this adapter, and which Discord connector/API should tools/chat-discord/ target?

2. For list_channels(), should “public” mean channels generally visible to normal server members (rather than simply anything visible to an authenticated bot/account with elevated permissions)?

3. If the chosen Discord integration does not provide server-wide author/channel/date message search, would bounded traversal of the configured public channels be an acceptable implementation for search_messages()?

4. For resolve_user(), I assume an explicit GitHub handle/link exposed in the Discord profile can yield confirmed_by: "profile", while username/display-name similarity alone should remain confirmed_by: null.

5. For answers_question, should Discord replies be evaluated against the directly referenced message, or the thread/root message when threads/forums are involved?

Once the intended Discord access mechanism is clear, I’m planning to mirror chat-slack: strictly public/read-only operations, no DM/private/write capabilities, plus the registry/vendor-neutrality updates and relevant contributor-growth eval coverage.

Happy to take this on if that matches the intended direction.