build: release build of admin, user apps and api

Rebuilt dist/ and api release bundle, with the migration for catalog paging indexes.

Fix Less build error: fade(@token, N%) on theme tokens failed in both user-app
and user-app-v2 CustomerChoiceView; use alpha(), the project's token-aware helper.

Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>

apps/api/release/vendor/.prisma/client/schema.prisma

@@ -667,6 +667,18 @@ model Product {
   promotions      Promotion[]
   allocationItems BranchAllocationItem[]
   favoritedBy     CustomerFavorite[]
+
+  // Storefront paging (owner: the real catalogue reaches ~16k products, so
+  // GET /catalog/products must page rather than return everything). This model
+  // had NO index at all, so every storefront query was a full scan and paging
+  // alone would not have been any faster.
+  //
+  // The composite matches the list's own shape: filter on isActive, order by
+  // createdAt — Postgres can satisfy both from this one index, including the
+  // OFFSET walk. The other two serve the category and brand filters.
+  @@index([isActive, createdAt])
+  @@index([categoryId])
+  @@index([brandId])
 }
 
 model ProductImage {
@@ -684,6 +696,11 @@ model ProductImage {
   /// variants (one photo, several weights), which is why this is a plain
   /// one-to-many and not a join table.
   variants ProductVariant[]
+
+  // The storefront list filters on `images: { some: {} }` and includes the
+  // gallery ordered by sortOrder, both per product. Unindexed, each one scanned
+  // the whole table.
+  @@index([productId, sortOrder])
 }
 
 enum ProductImageRole {
@@ -721,6 +738,10 @@ model ProductVariant {
   orderItems OrderItem[]
 
   @@index([imageId])
+  // Every storefront product carries its variants, so this include ran once per
+  // product with no index to use. The composite covers the `isActive: true`
+  // filter the list applies to them.
+  @@index([productId, isActive])
 }
 
 // ─────────────────────────────────────────────────────────────────────────