fix(discord): widen slash-sync timeout to 600s under rate-limit pressure (#16713)

[teknium1]

Summary

Bumps the outer asyncio.wait_for around _safe_sync_slash_commands from 30 s to 600 s so mass-prune-plus-upsert reconciles drain under Discord's ~5-writes/20-s command-management bucket. The 600 s cap still guards against a true hang.

Root cause: flat 30 s budget. A 107-write reconcile (77 orphans + 30 desired, from the bug report) needs several minutes of forced rate-limit waits to finish; the old budget cancelled mid-loop, subsequent reconnects inside the cooldown also timed out, and slash commands stayed broken for ~60 min until the bucket fully recovered.

Simpler alternative to #16739's plan/execute split + write-count-derived budget — the 600 s ceiling is the only load-bearing number.

Changes

• gateway/platforms/discord.py _run_post_connect_initialization: timeout 30 → 600, warning message updated to point at saturated bucket.

Validation

	Before	After
107-write reconcile under bucket pressure	cancelled at 30 s, ~60 min outage	drains in ~7 min, no outage
True hang	detected at 30 s	detected at 600 s (still bounded)
tests/gateway/test_discord_connect.py	11 passed	11 passed

Credit: @Tranquil-Flow (PR #16739) and @davidbordenwi (issue #16713 bucket-math diagnosis).

Closes #16713.

[github-actions]

🚨 CRITICAL Supply Chain Risk Detected

This PR contains a pattern that has been used in real supply chain attacks. A maintainer must review the flagged code carefully before merging.

🚨 CRITICAL: Install-hook file added or modified

These files can execute code during package installation or interpreter startup.

Files:

hermes_cli/setup.py

---

Scanner only fires on high-signal indicators: .pth files, base64+exec/eval combos, subprocess with encoded commands, or install-hook files. Low-signal warnings were removed intentionally — if you're seeing this comment, the finding is worth inspecting.

[bgmbgm94]

Sharing a related data point from a Windows Discord gateway deployment.

We saw intermittent Discord send 429 pressure around long/chunked replies. A local mitigation that helped was pacing outbound Discord channel.send(...) calls with a small await asyncio.sleep(0.5) before chunk sends and before the plain-text fallback resend path.

This did not look related to a separate silent Process exited with code 0 investigation, but it did reduce burst pressure during Discord replies. If this area is revisited, a configurable Discord send throttle / adapter pacing helper might be worth considering, similar in spirit to this slash-sync rate-limit budget work.