Summary

• apply channels.discord.proxy to Discord REST calls made during monitor startup
• route application-id lookup and allowlist resolvers through the same proxy used by gateway config
• update config help text to clarify proxy now covers gateway + API requests
• add unit tests for REST proxy fetch wiring and invalid-proxy fallback

Why

In restricted networks, gateway proxy could be enabled while startup REST calls still used direct network access, causing:

• Failed to resolve Discord application id
• allowlist resolution failures before monitor fully starts

This change makes startup behavior consistent with proxy configuration.

Testing

• pnpm vitest run --config vitest.unit.config.ts src/discord/monitor/provider.rest-proxy.test.ts src/discord/monitor/provider.proxy.test.ts src/discord/monitor/provider.skill-dedupe.test.ts

Greptile Summary

Routes Discord startup REST calls (application-id lookup and allowlist resolution) through the same proxy configured via channels.discord.proxy, fixing failures in restricted networks where the gateway proxy was enabled but REST calls used direct access.

• Adds resolveDiscordRestFetch() in provider.ts using undici.ProxyAgent — mirrors the established pattern in src/telegram/proxy.ts
• Threads the proxy-aware fetcher into resolveDiscordChannelAllowlist, resolveDiscordUserAllowlist, and fetchDiscordApplicationId
• Gracefully falls back to global fetch on invalid proxy URLs with error logging
• Updates config help text to clarify the proxy scope now covers gateway + API requests
• Adds unit tests covering valid proxy routing and invalid-proxy fallback

Confidence Score: 5/5

• This PR is safe to merge — it follows established proxy patterns from the Telegram provider and all downstream consumers already accept an optional fetcher parameter.
• The changes are straightforward and follow the exact same proxy pattern used in src/telegram/proxy.ts. The new resolveDiscordRestFetch function mirrors makeProxyFetch, the type casting is identical, and the error-handling fallback is robust. All three call sites (fetchDiscordApplicationId, resolveDiscordChannelAllowlist, resolveDiscordUserAllowlist) already accept an optional fetcher parameter, so the plumbing is seamless. The help text update is accurate. Tests cover both the happy path and error fallback.
• No files require special attention.

_{Last reviewed commit: 6043f56}

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}