bug: Telegram menu errors are silently swallowed — zero observability #90

Summary

The Telegram menu system introduced in #86 has pervasive silent failure patterns. Errors vanish with no log output, making production debugging impossible.

Bugs

1. Empty catch blocks in menuHandler

src/telegram/menuHandler.ts:177-180, 303-306, 402-404

Three catch blocks use bare catch { } with no bound variable and no logging:

• doCancelIntent (line 177) — hides IntentNotFoundError, IllegalTransitionError, DB errors
• doCancelCard (line 303) — hides Stripe errors, DB errors
• Outer handleMenuCallback catch (line 402) — covers six operations including savePrefPolicy, savePrefTtl, and all menu actions

Users see "Something went wrong"; developers have no trace. In the case of doCancelIntent, the user may believe their intent was cancelled when it was not.

2. editMenu swallows all Telegram API errors

src/telegram/menuHandler.ts:52-58

await bot.api.editMessageText(...).catch(() => {});

This catches everything — including 403 (bot blocked), 429 (rate limit), network timeouts. The intent was to ignore the benign "message not modified" 400 error, but the implementation discards all errors. If Telegram calls are silently failing, users receive no feedback and developers have no signal.

Fix: distinguish the expected "not modified" error from genuine failures:

.catch((err) => {
  if (err?.error_code === 400 && String(err?.description).includes('message is not modified')) return;
  console.error({ message: 'Failed to edit Telegram menu', chatId, messageId, error: String(err) });
  throw err;
});

3. Unvalidated TTL values from Telegram callbacks

src/telegram/menuHandler.ts:397-399

parseInt(payload, 10) is called on the callback payload with no range validation before writing to the DB. A crafted menu_pref_ttl:-1 or menu_pref_ttl:99999 callback bypasses all validation (the API-level Zod schema enforces 1–10080 but the Telegram path does not).