Arm the delayed ability refresh on subclass equipment swaps too

Invalidating the ability-buckets domain on a subclass swap was not enough on its
own: the domain's rebuild runs asynchronously off the content-extraction pump,
and the appearance/roster refreshes staged right after the equip commit can
easily race ahead of it, publishing the stale (pre-swap) resolution. Opcode 801
ability-entry picks already owed a delayed re-derivation for exactly this
race; the equipment-swap path needs the same one whenever the swapped slot is
the subclass slot, which is what actually fixes the stale-until-forced-refresh
symptom.

Sunrise/src/server/bap/encrypted/queuez/queuez_outcome_staging.cpp

@@ -75,6 +75,13 @@ bool stage_service_outcome(Scratch& scratch,
         }
         middleware::secure_channel::advance_nonce(nonce);
         after = swap.after;
+        // Swapping the subclass slot invalidates the published ability buckets the same way an
+        // opcode-801 pick does; the rebuild is likewise asynchronous, so this owes the same
+        // delayed re-derivation rather than risking a race with whatever refresh runs below.
+        if (equipment->pending.equipmentSlotIndex
+            == static_cast<std::size_t>(state::account::inventory::EquipmentSlot::subclass)) {
+            armsAbilityRefresh = true;
+        }
         // Family four drives inventory placement, while Family zero owns the rendered appearance
         // consumed by the open cosmetic panels and world player. Its resident character record is
         // updated in place: releasing and re-adding the same key tears down the ship/banner