In `@src/Appwrite/Platform/Workers/Messaging.php`:
- Around line 599-612: When batching multiple recipients in Messaging.php the
current logic sets $to = [] if $fromEmail is not provided, causing downstream
adapters (which expect at least one TO recipient via getTo()) to fail; change
the handling in the block that moves recipients to BCC so that if $fromEmail is
empty you keep the first recipient in $to and move the remaining recipients to
$bcc (i.e., set $to = [array_shift($to)] and push the rest into $bcc), ensuring
$to is never empty while still hiding other recipients; reference the $to, $bcc
and $fromEmail variables and the provider['options']['fromEmail'] usage when
applying the change.

In `@src/Appwrite/Platform/Workers/Messaging.php`:
- Around line 599-618: The current logic in Messaging.php moves all original
recipients to BCC and sets $to = [$fromEmail] when $fromEmail is present, which
causes the sender to receive every batch email; instead, always pick the first
original recipient as the TO and move the remaining $to entries to $bcc
regardless of $fromEmail. In the block handling multiple recipients (variables
$to, $bcc, $fromEmail), change the flow to array_shift $to into $first, push the
remaining recipients into $bcc as ['email' => $recipient], and set $to =
[$first]; do not set $to to $fromEmail or otherwise add $fromEmail into
$to/envelope so the sender is not an automatic delivery target. Ensure the
fallback branch is removed or unified so both code paths use this
first-recipient-as-TO pattern.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/Appwrite/Platform/Workers/Messaging.php`:
- Around line 599-606: The current logic in Messaging.php leaves the first
recipient in $to when multiple recipients are present, exposing that address;
change to send per-recipient (batch size = 1) instead of a single message with
BCC: iterate over the original recipient list and, for each recipient, set $to
to that single recipient and clear $bcc before calling the existing send routine
(the method that ultimately sends the message in this class), or build
per-recipient message objects and call the send method for each; ensure $to and
$bcc are only populated for the single target so no recipient ever sees another
recipient’s address.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/Appwrite/Platform/Workers/Messaging.php`:
- Around line 254-263: The code forces $maxMessagesPerRequest = 1 for
MESSAGE_TYPE_EMAIL which causes N concurrent batch() coroutines for N recipients
and can burst provider rate limits; update the logic around
getMaxMessagesPerRequest()/MESSAGE_TYPE_EMAIL and the batching that builds
$batches so that email sends either respect the provider's bulk capacity or are
subject to a per-provider concurrency/send-rate limiter before invoking batch():
use getMaxMessagesPerRequest() as the upper bound, or implement a concurrency
cap/rate limiter keyed by the provider (e.g., wrap calls from batch() with a
provider-specific semaphore/tokens or throttle) and ensure delivery errors
($deliveryErrors) still record failures but backoff/retry or queue excess
batches instead of launching unlimited coroutines.
- Around line 254-262: The code currently calls
$adapter->getMaxMessagesPerRequest() unconditionally and then overrides
$maxMessagesPerRequest when $provider->getAttribute('type') ===
MESSAGE_TYPE_EMAIL; change the order so you first check the provider type and
only call $adapter->getMaxMessagesPerRequest() when the provider is not an email
(MESSAGE_TYPE_EMAIL), setting $maxMessagesPerRequest = 1 for emails otherwise;
update the logic around $maxMessagesPerRequest (used in array_chunk with
array_keys($identifiersForProvider)) so the call is deferred and avoids the
unnecessary getMaxMessagesPerRequest() invocation for email adapters.