Unsent changes from one account could land on the server as another
account signed in on the same device. The queue checked the account
before claiming a batch, then awaited the claim's durable writes and
sent without checking again, so a sign-out and sign-in in that window
sent the first account's batch as the second. The transport also keeps
a pending request across a sign-out and resends it after the next
sign-in. Either way, if the new account could edit the strategy and
the revision still matched, the work landed as theirs.

applyBatch now takes an optional accountSubject. When it is given and
is not the signed-in identity's subject, the server refuses the whole
batch with FORBIDDEN before any op, so nothing is applied or recorded
and the same op ids land later for the right account. The queue always
sends it, taken from the outbox records' account, never from whoever
is signed in at send time. Older clients send no subject and keep
their behavior.

After the claim, the queue checks the account again. If it changed,
signed out, or has an auth incident, the claimed records go back to
their own account's queue with the same op ids and no attempt counted,
to send when that account is signed in again.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>