Serialize folder mutations across tabs

Problem

The worker outbox serializes message mutations by target_message_id, but folder mutations have no shared folder target and receive row-unique lock keys. Pending folder state in Pinia is also tab-local.

Two tabs can therefore enqueue subscription, rename, move, or delete operations for the same folder concurrently. The requests may execute out of order and produce confusing last-write-wins behavior or policy errors.

This was intentionally deferred from the shared-folder stack.

Suggested initial fix

Because folder mutations are comparatively rare, serialize all Mailbox mutations through one lock key per JMAP backend/session in the SharedWorker. A later optimization may refine this to one lock per owning account or Mailbox target.

Acceptance criteria

• Folder mutations from separate tabs execute in deterministic queue order.
• Mutations for the same folder cannot interleave.
• Message mutation concurrency remains unchanged.
• Failure of one folder mutation does not permanently block later queued folder mutations.
• Browser-level tests exercise two tabs against the same SharedWorker.

Start by tracing the SharedWorker worker outbox, its folder and message lock keys, and the Pinia pending-folder state. Run or extend the browser-level tests with two tabs against the same SharedWorker; done means folder mutations queue deterministically, same-folder mutations do not interleave, message concurrency is unchanged, and a failed mutation does not block later ones.