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/migrations/20261012120000_catalog_paging_indexes/migration.sql

@@ -0,0 +1,30 @@
+-- Catalogue paging indexes.
+--
+-- Owner, 2026-10-12: «دیتاها در اپ واقعی تا 16 هزار رکورد میرود و گرفتن همه یک
+-- جا اشتباه است، حتما باید پیج نیشن داشته باشد.» Step 1 of
+-- docs/CATALOG-PAGINATION-PLAN.md: without these, server-side paging would walk
+-- the same full table scans the unpaged query did.
+--
+-- `Product` carried NO index whatsoever, so every GET /catalog/products was a
+-- sequential scan, and so was each per-product include.
+--
+-- IF NOT EXISTS throughout: these run under BOTH migration paths (D15) — the
+-- Prisma CLI in development and the app's own runner in the deploy image.
+--
+-- CREATE INDEX (not CONCURRENTLY): the app's runner wraps each migration in a
+-- transaction, which CONCURRENTLY cannot join. On a 16k-row table this locks
+-- writes for a few hundred milliseconds, which is acceptable; a table large
+-- enough to matter would need the index built by hand outside a migration.
+
+-- Matches the storefront list exactly: filter isActive, order by createdAt.
+CREATE INDEX IF NOT EXISTS "Product_isActive_createdAt_idx" ON "Product" ("isActive", "createdAt");
+
+-- The category and brand filters of the search screen.
+CREATE INDEX IF NOT EXISTS "Product_categoryId_idx" ON "Product" ("categoryId");
+CREATE INDEX IF NOT EXISTS "Product_brandId_idx" ON "Product" ("brandId");
+
+-- `include: { variants: { where: { isActive: true } } }`, once per product.
+CREATE INDEX IF NOT EXISTS "ProductVariant_productId_isActive_idx" ON "ProductVariant" ("productId", "isActive");
+
+-- `where: { images: { some: {} } }` plus the gallery ordered by sortOrder.
+CREATE INDEX IF NOT EXISTS "ProductImage_productId_sortOrder_idx" ON "ProductImage" ("productId", "sortOrder");

apps/api/release/vendor/.prisma/client/deno/edge.d.ts

@@ -0,0 +1,9 @@
+class PrismaClient {
+  constructor() {
+    throw new Error(
+      '@prisma/client/deno/edge did not initialize yet. Please run "prisma generate" and try to import it again.',
+    )
+  }
+}
+
+export { PrismaClient }

apps/api/release/vendor/.prisma/client/package.json

@@ -1,5 +1,5 @@
 {
-  "name": "prisma-client-e147fca6a8936b4d1db4feed20443e1fd9688a3faaaea60d3aac27120c23cee3",
+  "name": "prisma-client-2865f0245bc905fafa9ec2b299c03c4ad7a157188246b5449e2f920f2b3a6c3d",
   "main": "index.js",
   "types": "index.d.ts",
   "browser": "index-browser.js",

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])
 }
 
 // ─────────────────────────────────────────────────────────────────────────