The revision was commissioned partly to stop the inbound limiter's Map from growing with every chat (ratelimit.ts item 2). The new outbound pacer reintroduces the same unbounded growth: wait() does nextByChat.set(chatId, sendAt + 1_000) on every send and nothing ever deletes an entry, even though an entry whose value is in the past has no effect on any later send. A long-running bot that answers many distinct chats keeps one Map entry per chat forever.

Both TelegramTransport and ScriptedTransport own such a pacer. No test covers it; a test that sends to N distinct chats, advances the injected clock past one second and asserts the Map shrinks would fail today.

The test proves the second message to one chat waits one second, but it never checks that the wait compounds. The per-chat limit depends on the reservation being made from the reserved slot (sendAt + 1_000, transport.ts line 38) and not from the current time.

Mutating that one line to nextByChat.set(chatId, now + 1_000) keeps all 11 tests green (verified on a copy: pass 11, fail 0), yet with that code the third message to the same chat is sent 33 ms after the second, which violates the limit the task asked the tests to prove. The thirty-per-second test does not catch it either because it uses 31 distinct chats.

Adding a third sendMessage(42, ...) and asserting clock.sleeps deep-equals [1000, 1000] (or send times [0, 1000, 2000]) closes the gap.

Both pacing tests drive ScriptedTransport. The live TelegramTransport, which is the transport the task named and the only one index.ts runs, is never constructed in the harness, so its wiring to OutboundPacer is proven only by inspection. The pacer class itself is correctly exercised through the injected clock (the tests assert the sleep durations the transport requested, not the fake's configuration), but the production path can lose pacing without any test noticing.

A harness test can construct TelegramTransport('test-token', fakeClock) with globalThis.fetch temporarily replaced by a stub that returns {ok:true,result:{}} and assert the same sleep sequence; no network and no real token are needed.

The eviction added for item 2 iterates the whole Map on every check(), so the cost of one inbound command is linear in the number of chats seen within the window. The eviction test and behaviour are correct; this is a note on the chosen approach, not a defect in what was asked. Evicting lazily per key plus an occasional sweep, or sweeping only when the Map exceeds a threshold, keeps the memory fix with constant per-message cost.