fix: give the getUpdates client its own connection pool

[mzored]

Description

Long polling in python-telegram-bot uses a separate HTTP client from the one configured in initialize(), and its connection pool holds a single connection by default. If a long-running getUpdates request is torn down mid-flight, that connection can stay checked out and every later poll fails immediately with Pool timeout: All connections in the connection pool are occupied — permanently, even after the network recovers. The process stays alive and the retry loop keeps running, so the bot looks healthy while receiving nothing.

This sets get_updates_connection_pool_size(8) so the poller has headroom to recover on its own. Same class of problem as #166, which fixed pool corruption for the main client only.

Related Issue

Fixes #213 — full analysis and reproduction there.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Changes

• src/bot/core.py: set get_updates_connection_pool_size(8) on the application builder.
• tests/unit/test_bot/test_core_connection_pool.py: assert the getUpdates client is not left on the default single-connection pool.

Testing

• Tests added/updated
• All tests pass — 531 passed
• Manual testing completed

Reproduced deterministically by severing the connection to the upstream mid-getUpdates for ~60s and then restoring it. Before: ~60 Pool timeout errors per minute after restore, zero successful requests, CLOSE_WAIT socket persisting. After: three consecutive cycles, polling recovers each time, no CLOSE_WAIT accumulation.

The new test fails on main and passes with the fix.

Checklist

• make format has been run (black, isort, flake8 clean)
• Code follows project style guidelines
• Self-review completed
• Documentation updated — not applicable
• No breaking changes