fix(teams): recover stalled photo downloads and bound image batches

[Proxicon]

Teams image downloads still reached the 60-second deadline after PR #61. The deployed container took 40.6 seconds for 693 KB and 56.6 seconds for 1.27 MB. Larger or slower transfers could therefore fail before the model received an image.

Teams and Discord use the same bounded stream-to-file helper. Their download endpoints differ. The logs establish slow Teams transfers, but do not identify the external cause.

This correction stays within the Teams adapter, actors, tests, and documentation:

• Permit image transfers for up to 240 seconds while each body read has a 30-second idle limit.
• Retry one idle body transfer within the same absolute deadline. Close the failed response and remove its partial file first.
• Process up to three images concurrently within one 270-second batch. Preserve attachment order and serialize the final file reservation and move.
• Keep the route deadlines below the SDK's five-minute limit. Report an explicit batch timeout for incomplete work.
• Apply the image budget to wildcard and concrete image declarations. Preserve concrete MIME and filename checks.
• Record safe per-attempt byte and duration facts without URLs, tokens, body data, or raw exceptions.

The change preserves access controls, file policies, canonical session history, terminal acknowledgements, and the existing safe-text behavior. It does not change Discord, shared download code, provider code, configuration schemas, or permissions.

The investigation and operator retest are in docs/teams/image-transfer-progress-and-recovery.md. This PR follows #63.

Validation:

• Teams suite: 373 passed, no failures or skips.
• Full Release build: no errors; one existing ASPIRE010 demo warning.
• Full solution tests: 8,553 passed, no failures, 17 existing platform or opt-in skips.
• Slopwatch, copyright headers, BOM checks, document links, Teams file scope, and git diff --check pass.
• New tests cover a real PNG larger than two MiB across 80 virtual seconds, idle retry, exact bytes, cleanup, redaction, and actor batch recovery.

The owner reviews, monitors CI, merges, deploys, and retests the existing personal conversation and channel threads. The live retest must confirm transfer reliability. The adapter still enforces finite limits for stalled services and large batches.