fix(telegram): bound the per-user API key cache

[anhtahaylove]

Fixes #13165.

Problem

resolveUserApiKey() cached a plaintext OmniRoute API key per Telegram user id in a module-level Map with no cap, no TTL and no eviction path. Every distinct id ever seen was retained for the lifetime of the process.

The id is not bounded by the real user population: POST /api/telegram/update reaches proxyChat(chat.chatId, ...) on the webhook path with the id taken straight from the request body, gated only by isTelegramEnabled().

Measurement

Driving the real module with getApiKeys/createApiKey stubbed (no DB access):

distinct users  : 20000
heap growth     : 4.9 MB
per-user cost   : 254 bytes
evictions       : 0

Fix

All three write sites now go through a rememberUserApiKey() helper backed by a 1000-entry LRU. Map insertion order is the recency order: a cache hit re-inserts the id, so an active user is not evicted by a burst of new ids, and the oldest entry is dropped once the cap is reached.

Tests

tests/unit/telegram-keycache-bounded-13165.test.ts (node:test, matching this directory's runner):

• evicts a cold id once the cap is exceeded — red before the fix (got 0 mint(s)), green after.
• keeps a recently used id alive across a burst of new ids — guards the LRU recency contract, so the fix cannot regress into a plain "clear when full" cache.

Verified in both directions on this branch: with the patch stashed the first test fails, with it restored both pass. tsc -p tsconfig.json --noEmit is clean.

Note for maintainers (not addressed here)

A cache miss falls through to createApiKey(), so a distinct id on the unauthenticated webhook path also mints and persists a new API key row, not just a memory entry. I did not change auth behaviour in a leak fix; flagged in #13165 for a separate decision.