feat(promo-codes): finish TOCTOU fix — remove post-facto check, add tests

Step 3 of 3. The per-member QuantityPerAccount check now lives solely
in PreProcessReservationTask::reserveMemberQuotas (added in ad113d5,
leak-guarded in 77c3059), where it runs atomically under the
PESSIMISTIC_WRITE row lock on the parent promo code, BEFORE
ReserveTicketsTask and ReserveOrderTask commit any tickets.

Changes:

- Remove the belt-and-suspenders post-facto check from
  ApplyPromoCodeTask::run. A comment now points at the pre-reservation
  location and links to smarcet's TOCTOU reproduction for context.
  The old check counted committed tickets and could not distinguish
  concurrent orders' rows — see the race narrative in PR #525.

- Delete tests/Unit/Services/ApplyPromoCodeTaskConcurrencyTest.php.
  smarcet added this in the cherry-picked 2e0ef84 to prove the TOCTOU
  bug against the old check surface (static
  getTicketCountByMemberAndPromoCode). That surface is no longer in
  the write path, so the test targets removed code. The narrative is
  preserved — and extended — in the new file below.

- Delete tests/Unit/Services/ApplyPromoCodeTaskQuantityPerAccountTest.php.
  All six cases validated the exact post-facto check that was just
  removed.

- Add tests/Unit/Services/PreProcessReservationTaskConcurrencyTest.php
  with 6 cases exercising the new surface via reflection on
  reserveMemberQuotas:
    1. First reserve succeeds when no prior row exists (repo `add`
       called with qty_used=1).
    2. Second reserve rejects when the prior row's QtyUsed already
       sits at the limit (the serialized-second-request flow that
       replaces smarcet's TOCTOU reproduction).
    3. Within-limit reserve increments the existing row.
    4. Limit = 0 bypasses reservation entirely (unlimited per account).
    5. Non-IDomainAuthorizedPromoCode codes are skipped (no
       reservation repo calls).
    6. undo() decrements each reserved counter exactly once and is
       idempotent via the $undone guard.

Verified:
  docker exec summit-api composer dump-autoload    # pick up new entity
  docker exec summit-api vendor/bin/phpunit --filter "PreProcessReservationTask|SagaCompensationTest|ApplyPromoCodeTask"
    → 13/13 pass (3 PHPUnit deprecations match repo baseline).

Outstanding from smarcet's PR #525 review: #7 (discoverPromoCodes N+1)
is the only remaining item.

Author: caseylocker

app/Services/Model/Imp/SummitOrderService.php

@@ -815,43 +815,13 @@ public function run(array $formerState): array
                     }
                 }
 
-                // QuantityPerAccount enforcement for domain-authorized promo codes.
-                //
-                // IMPORTANT — the condition below is `>`, NOT `>=`, and we do NOT add $qty.
-                // That is because $existingCount ALREADY INCLUDES the current order's
-                // tickets. The saga runs ReserveOrderTask before ApplyPromoCodeTask;
-                // ReserveOrderTask calls $promo_code->applyTo($ticket), which sets
-                // PromoCodeID on each new ticket, and its transaction commits before
-                // this task's transaction opens. getTicketCountByMemberAndPromoCode
-                // is a raw SQL count over SummitAttendeeTicket joined to SummitOrder
-                // with status IN ('Reserved','Paid','Confirmed'), so the in-flight
-                // order's freshly-reserved tickets are already counted.
-                //
-                // Examples (limit = 2, prior tickets = 0):
-                //   buying 2 -> existingCount=2 -> 2 > 2 false -> allowed (exactly at cap)
-                //   buying 3 -> existingCount=3 -> 3 > 2 true  -> rejected
-                // Examples (limit = 2, prior tickets = 2):
-                //   buying 1 -> existingCount=3 -> 3 > 2 true  -> rejected
-                //
-                // If the saga order changes, or PromoCodeID assignment moves out of
-                // ReserveOrderTask, the semantics here break — revisit this check.
-                if ($promo_code instanceof IDomainAuthorizedPromoCode
-                    && !is_null($this->owner)
-                ) {
-                    $quantityPerAccount = $promo_code->getQuantityPerAccount();
-                    if ($quantityPerAccount > 0) {
-                        $existingCount = $this->promo_code_repository->getTicketCountByMemberAndPromoCode($this->owner, $promo_code);
-                        if ($existingCount > $quantityPerAccount) {
-                            throw new ValidationException(
-                                sprintf(
-                                    "Promo code %s has reached the maximum of %s tickets per account.",
-                                    $promo_code_value,
-                                    $quantityPerAccount
-                                )
-                            );
-                        }
-                    }
-                }
+                // QuantityPerAccount enforcement lives in PreProcessReservationTask.
+                // That's where the check-and-increment runs atomically under the
+                // PESSIMISTIC_WRITE row lock on the promo code, BEFORE ReserveOrderTask
+                // commits tickets. A post-facto count here (as this task did prior to
+                // the TOCTOU fix) cannot distinguish the current order's freshly-
+                // committed tickets from a concurrent order's — see smarcet's
+                // reproduction in tests/Unit/Services/ApplyPromoCodeTaskConcurrencyTest.
 
                 Log::debug(sprintf("adding %s usage to promo code %s", $qty, $promo_code->getId()));