fix(promo-codes): harden reservation backfill per Codex review

Three no-behavior-change safety nits from the step-1 audit:
- Version20260415191522 backfill now uses GREATEST(QtyUsed, VALUES(QtyUsed))
  on the ON DUPLICATE KEY path so a re-run after live saga writes can
  never clobber a newer counter with a stale historical count.
- Version20260415191522.down() is now a documented no-op. The previous
  TRUNCATE would have silently zeroed live counters once step 2 lands.
  Roll back Version20260415191521 if a clean slate is needed.
- ISummitPromoCodeMemberReservationRepository docblock is reworded so
  the 'outer lock' statement is explicit as a CALLER PRECONDITION,
  not something the repository guarantees or enforces.

Migration down/up round-trip re-verified on docker MySQL.

Remaining step-1 concern — undo idempotency of the entity's decrement
helper — is deferred to step 2, where the saga caller is the right
place to guard duplicate undo invocations (mirror the 'redeem' flag
pattern already used by ApplyPromoCodeTask::undo).

Author: caseylocker

app/Models/Foundation/Summit/Repositories/ISummitPromoCodeMemberReservationRepository.php

@@ -24,11 +24,12 @@ interface ISummitPromoCodeMemberReservationRepository extends IBaseRepository
     /**
      * Look up the per-member reservation row for a given promo code.
      *
-     * Callers invoking this from the reservation path must already hold an
-     * exclusive row lock on the parent SummitRegistrationPromoCode (via
-     * ISummitRegistrationPromoCodeRepository::getByValueExclusiveLock). That
-     * outer lock is what serializes concurrent access to this row — no
-     * separate PESSIMISTIC_WRITE is taken here.
+     * CALLER PRECONDITION (not enforced here): when invoked from the order
+     * reservation write path, the caller must already hold an exclusive row
+     * lock on the parent SummitRegistrationPromoCode via
+     * ISummitRegistrationPromoCodeRepository::getByValueExclusiveLock. That
+     * outer lock is what serializes concurrent writes; this method does not
+     * (and cannot) take or verify the lock itself.
      *
      * @param SummitRegistrationPromoCode $code
      * @param Member $member

database/migrations/model/Version20260415191522.php

@@ -56,16 +56,19 @@ public function up(Schema $schema): void
   AND o.Status IN ('Reserved', 'Paid', 'Confirmed')
   AND t.Status != 'Cancelled'
 GROUP BY t.PromoCodeID, o.OwnerID
-ON DUPLICATE KEY UPDATE QtyUsed = VALUES(QtyUsed), LastEdited = NOW()
+ON DUPLICATE KEY UPDATE
+    QtyUsed    = GREATEST(QtyUsed, VALUES(QtyUsed)),
+    LastEdited = NOW()
 SQL
         );
     }
 
     public function down(Schema $schema): void
     {
-        $builder = new Builder($schema);
-        if ($builder->hasTable('SummitPromoCodeMemberReservation')) {
-            $this->addSql('TRUNCATE TABLE SummitPromoCodeMemberReservation');
-        }
+        // No-op: re-running the backfill is safe (GREATEST preserves live
+        // counter values), but truncating the table on rollback would silently
+        // zero live reservations after the saga starts writing. The safer
+        // inverse is simply "nothing"; roll back Version20260415191521 to drop
+        // the table entirely if you need a clean slate.
     }
 }