fix: buffer Telegram photo-album messages into a single Claude request

[IliyaBrook]

Follow-up to the discussion in #186 — @MatveyF flagged that the same
"one logical message, N responses" problem happens with images:

if I attach images to my message I get a response per image.
E.g. if I send a piece of text with 3 images it will respond 3 times —
one for the text and the first image, second for the second image,
and third for the third image

Root cause

When a user sends a Telegram album (text + N photos), Telegram delivers
it as N separate Updates that share a common message.media_group_id;
the caption lives on only one of them. The agentic photo handler fires
once per Update, so Claude is invoked N times independently instead of
seeing the album as a single message.

Fix

• New MediaGroupBuffer (src/bot/utils/media_group_buffer.py) —
  debounces photos keyed by (user_id, chat_id, thread_id, media_group_id).
  Any photo carrying a media_group_id is buffered; a short timer
  (default 1.0s, configurable via MEDIA_GROUP_BUFFER_TIMEOUT, range
  0.3 – 5.0) fires after the last photo and flushes all photos +
  caption as a single payload.
• agentic_photo refactored into a dispatcher: standalone photos take
  the existing fast path; album photos go through the buffer.
• Shared work extracted to _process_photo_batch — the first photo is
  processed with the caption (so the prompt template keeps user intent),
  the rest are processed for image data only, and a single
  claude_integration.run_command is issued with all images attached.
• The Stop button cancels any pending media-group buffers for the user.

[RichardAtCT]

Thanks — the album handling works, and the tests drive real timers rather than mocks. I want it. Three things first.

1. Do not ship two buffers. media_group_buffer.py and the message_buffer.py from #187 are the same machine. _schedule_timer, _cancel_timer, _delete_message, pending_keys, has_buffer, cancel and the status-message lifecycle are line-for-line the same. Only the accumulator differs: a string join there, a list append here.

Two copies will drift. You already fixed a double _delete_message call here that #187 still has, and that fix will not reach it.

Please pull the timer and cancel machinery into one primitive, and let each buffer supply only its accumulator and flush policy.

2. A late photo starts a second request. The timer pops the entry, so a straggler with the same media_group_id creates a fresh entry and fires again a second later. Keep a short-lived set of recently flushed ids so a late photo joins nothing.

3. Add one orchestrator-level test. The buffer itself is well covered, but the album-vs-standalone dispatch and the multi-image payload are not, and that is where the behaviour the user sees lives.

Minor: media_group_buffer_timeout has ge=0.3, so there is no way to turn buffering off. Allowing 0 would match PROJECT_THREADS_SYNC_ACTION_INTERVAL_SECONDS.

I am merging #187 first, so this needs a rebase either way. Do the rebase and the refactor together.