docs(gui): record why the pause path is not cross-gated with the pin writes

Pausing the pinned account releases the pin too, so the obvious reading of the
switch/order cross-gate is that pause was missed. It was not: that edge is
conditional on the pin still naming the paused account, so it is a no-op whenever a
concurrent write has already moved the pin elsewhere, and the client agrees with the
server whichever response lands last. The gated pair state a pin outright, which is
what makes response order decide the outcome.

Comment only -- worth having at the line, because the safe-looking fix (share
pauseMutationRef) would make a pause and an order change on two unrelated accounts
reject each other, and because copying the unconditional pattern here would
introduce the very race the gate exists to prevent.

Author: XertroV

gui/src/hooks/useCodexAccountPool.ts

@@ -301,6 +301,14 @@ export function useCodexAccountPool(apiBase: string, enabled = true): CodexAccou
         pendingActiveIdRef.current = { id: nextActiveId };
         setActiveId(nextActiveId);
       }
+      // Deliberately NOT cross-gated against the switch and order writes, even though
+      // pausing the pinned account also releases the pin. This edge is conditional on
+      // the pin still naming `id`, which makes it order-robust: whichever response
+      // lands last, the client agrees with the server. An unconditional edge is what
+      // forced the gate between those two -- each states a pin outright, so the later
+      // response wins regardless of which write the server applied last. Sharing a
+      // mutation ref here would instead make a pause and an order change on two
+      // unrelated accounts reject each other for no reason.
       if (paused) setActivePinnedId(current => current === id ? null : current);
       void load();
       return { ok: true } as const;
@@ -375,6 +383,9 @@ export function useCodexAccountPool(apiBase: string, enabled = true): CodexAccou
         pendingActiveIdRef.current = { id: nextActiveId };
         setActiveId(nextActiveId);
       }
+      // Conditional for the same reason as the single-account pause above: clearing
+      // outright would race the switch and order writes, which is why those two are
+      // gated against each other and these two do not need to be.
       setActivePinnedId(current => current !== null && pausedIds.has(current) ? null : current);
       void load();
       return { ok: true, pausedCount: result.pausedCount ?? pausedIds.size } as const;