silence secondary-bot 429 fallback noise from debug channel

Two paired logWarn calls used to post to DEBUGGING_CHANNEL_ID every time
the RENAMER_BOT secondary token hit Discord's per-channel rename quota:

  Warning: renamer        — "429 rename channel=… retry_after=…"
  Warning: renameQueue    — "secondary-bot 429; falling back to primary…"

Both fire on the recoverable path: the channelQueue immediately falls
back to the primary discord.js client, and that client's REST handler
transparently waits out the retry_after and retries — the rename lands
without operator action. Posting these to the debug channel was pure
noise; staff were reading them as failures when nothing had failed.

Demoted both to console.warn so they still appear in `docker logs
broccolini` for diagnostic purposes but no longer post to Discord.

Kept untouched:
- utils/renamer.js:64 — 401/403 logWarn on secondary-bot auth/permission
  errors (real config problems; the operator does need to know).
- services/channelQueue.js next.catch logError for status 401/403/429 —
  only fires when the fallback itself also failed (rare and worth a
  debug-channel post).

utils/renamer.js

@@ -41,7 +41,10 @@ async function renameChannel(channelId, newName) {
   if (res.status === 429) {
     const retryAfterSec = (body && typeof body === 'object' && body.retry_after) || null;
     const retryAfterMs = retryAfterSec != null ? Math.ceil(Number(retryAfterSec) * 1000) : null;
-    logWarn('renamer', `429 rename channel=${channelId} retry_after=${retryAfterSec}`).catch(() => {});
+    // Local log only; the channelQueue fallback path handles recovery
+    // transparently via discord.js's built-in 429 retry. Posting these to
+    // the debug channel was non-actionable noise.
+    console.warn(`[renamer] 429 rename channel=${channelId} retry_after=${retryAfterSec}`);
 
     // Respect retry_after up to 2000ms; otherwise fail over immediately.
     if (retryAfterMs != null && retryAfterMs > 0 && retryAfterMs <= 2000) {