refactor: rename marketplace to storefront across the entire monorepo

Comprehensive rename of all marketplace references to storefront:
- API module: apps/api/src/modules/marketplace/ → storefront/
- Components: MarketplaceHeader → StorefrontHeader, MarketplaceShell →
  StorefrontShell, MarketplaceFooter → StorefrontFooter
- Types: marketplace-homepage.ts → storefront-homepage.ts
- Test files: employee-marketplace-* → employee-storefront-*
- All source code identifiers, imports, route paths, and strings
- Documentation (docs/), CI config (.gitlab-ci.yml), scripts
- Dashboard, admin, storefront workspace references
- Prisma field names preserved (isListedOnMarketplace, marketplaceRating,
  marketplaceFunnelEvent) as they map to database schema

Validation:
- API type-check: 0 errors
- Storefront type-check: 0 errors
- Dashboard type-check: 0 errors
- Full monorepo type-check: only pre-existing admin TS18046

docs/project-design/API_REFACTOR_TASK_LIST.md

@@ -53,7 +53,7 @@ whenever new endpoints are added.
 Integration tests exist, but the heaviest workflows still benefit from deeper coverage:
 
 - subscription billing transitions
-- marketplace reservation intake
+- storefront reservation intake
 - public booking and payment initialization
 - reservation inspection and close flows
 - admin billing operations

docs/project-design/COOKIE_POLICY.md

@@ -52,7 +52,7 @@ We do not use analytics cookies, advertising cookies, or third-party tracking co
 | **Scope** | All pages (`path=/`) |
 | **Third-party** | No |
 
-**Purpose:** Stores your chosen display language so the interface appears in your preferred language on every visit across all parts of the platform (public marketplace, dashboard, and admin panel). Supported values are English (`en`), French (`fr`), and Arabic (`ar`).
+**Purpose:** Stores your chosen display language so the interface appears in your preferred language on every visit across all parts of the platform (public storefront, dashboard, and admin panel). Supported values are English (`en`), French (`fr`), and Arabic (`ar`).
 
 **When it is set:** When you change the language using the language selector, or automatically on first visit based on your browser's language settings.  
 **Can you opt out?** You can block this cookie. If you do, the platform will fall back to a default language and you may need to select your language on every visit.
@@ -97,7 +97,7 @@ We do not use analytics cookies, advertising cookies, or third-party tracking co
 
 | Field | Value |
 |---|---|
-| **Names** | `dashboard-language`, `marketplace-language` |
+| **Names** | `dashboard-language`, `storefront-language` |
 | **Category** | Functional / preference |
 | **Duration** | 1 year |
 | **Scope** | All pages (`path=/`) |

docs/project-design/FEATURES.md

@@ -4,7 +4,7 @@ This document lists the features that are active in the current codebase.
 
 Source of truth:
 
-- `apps/marketplace`
+- `apps/storefront`
 - `apps/dashboard`
 - `apps/admin`
 - `apps/api`
@@ -14,7 +14,7 @@ Source of truth:
 
 The current workspace contains four active apps:
 
-- `apps/marketplace`
+- `apps/storefront`
 - `apps/dashboard`
 - `apps/admin`
 - `apps/api`
@@ -61,12 +61,12 @@ There is no separate frontend app for a white-label company public site in this
 - Notification inbox and preferences
 - Subscription management
 
-### Marketplace and public platform
+### Storefront and public platform
 
 - Public marketing homepage
 - Public pricing page
 - Public features page
-- Public marketplace/explore flow
+- Public storefront/explore flow
 - Explore company profile pages under `/explore/[slug]`
 - Public review submission page via review token
 - Public legal/app policy pages
@@ -120,7 +120,7 @@ There is no separate frontend app for a white-label company public site in this
 - Billing operations
 - Pricing configuration and promotions
 - Notification review
-- Marketplace/site config management
+- Storefront/site config management
 
 ## Present But Not Active Product Features
 
@@ -144,9 +144,9 @@ The following old design ideas should not be treated as active features unless c
 - standalone about/contact page set
 - Google renter auth
 - automatic custom-domain provisioning
-- Zapier/webhook marketplace integrations beyond the current API/webhook handlers
+- Zapier/webhook storefront integrations beyond the current API/webhook handlers
 
 ## Notes
 
 - The database still contains legacy fields such as `Employee.clerkUserId`, but those fields are no longer evidence of active Clerk integration.
-- Some renter-facing `/renter/*` pages exist in the marketplace app, but the auth entrypoints they depend on are not active. They are therefore not listed as active product scope here.
+- Some renter-facing `/renter/*` pages exist in the storefront app, but the auth entrypoints they depend on are not active. They are therefore not listed as active product scope here.

docs/project-design/PAGES.md

@@ -4,15 +4,15 @@ This document lists the pages that are actually present in the current frontend
 
 Source of truth:
 
-- `apps/marketplace/src/app`
+- `apps/storefront/src/app`
 - `apps/dashboard/src/app`
 - `apps/admin/src/app`
 
-## Marketplace App
+## Storefront App
 
 App:
 
-- `apps/marketplace`
+- `apps/storefront`
 
 ### Public routes
 
@@ -37,11 +37,11 @@ App:
 
 - `/` is the public marketing home.
 - `/pricing` consumes platform pricing from `/site/platform/pricing`.
-- `/explore` is the public marketplace search/discovery page.
-- `/explore/[slug]` is the company marketplace profile page.
+- `/explore` is the public storefront search/discovery page.
+- `/explore/[slug]` is the company storefront profile page.
 - `/review` is the review submission page driven by a reservation review token.
 
-### Not present in the current marketplace app
+### Not present in the current storefront app
 
 - `/about`
 - `/contact`
@@ -51,7 +51,7 @@ App:
 
 ### Renter routes present in code but not active product entrypoints
 
-These routes exist in the marketplace app:
+These routes exist in the storefront app:
 
 - `/renter/dashboard`
 - `/renter/notifications`
@@ -114,7 +114,7 @@ Base path:
 - `/dashboard` shows KPIs and booking-source analytics.
 - `/dashboard/fleet*` manages vehicles, maintenance, and calendar blocks.
 - `/dashboard/reservations*` manages the booking lifecycle and inspection workflows.
-- `/dashboard/online-reservations` handles public/marketplace booking intake.
+- `/dashboard/online-reservations` handles public/storefront booking intake.
 - `/dashboard/customers` is the company CRM view.
 - `/dashboard/offers` manages promotions.
 - `/dashboard/team` manages employees.
@@ -164,7 +164,7 @@ App:
 - `/dashboard/billing` manages platform billing operations.
 - `/dashboard/pricing` edits platform pricing, features, and promotions.
 - `/dashboard/notifications` inspects platform notifications.
-- `/dashboard/site-config` edits marketplace/site configuration content.
+- `/dashboard/site-config` edits storefront/site configuration content.
 
 ## Deliberately Not Listed
 

docs/project-design/VULNERABILITY_FIXES_2026-05-22.md

@@ -8,7 +8,7 @@
 
 ## Summary
 
-A full security review of the API codebase identified 3 confirmed, high-confidence vulnerabilities. All 3 were fixed in the same session. A separate frontend scan (dashboard, admin, marketplace, public-site) found no confirmed vulnerabilities above the reporting threshold.
+A full security review of the API codebase identified 3 confirmed, high-confidence vulnerabilities. All 3 were fixed in the same session. A separate frontend scan (dashboard, admin, storefront, public-site) found no confirmed vulnerabilities above the reporting threshold.
 
 | # | Severity | Category | Status |
 |---|----------|----------|--------|
@@ -127,7 +127,7 @@ An authenticated employee from Company A could fetch the full maintenance histor
 
 ### Exploit Scenario
 
-An employee of Company A calls `GET /api/v1/vehicles/<vehicleId_from_company_B>/maintenance`. Vehicle UUIDs can leak through marketplace listings, shared bookings, or support interactions. The response contains the complete maintenance history of Company B's vehicle — including service records, mileage data, and operational schedules — across tenant boundaries.
+An employee of Company A calls `GET /api/v1/vehicles/<vehicleId_from_company_B>/maintenance`. Vehicle UUIDs can leak through storefront listings, shared bookings, or support interactions. The response contains the complete maintenance history of Company B's vehicle — including service records, mileage data, and operational schedules — across tenant boundaries.
 
 ### Fix
 
@@ -156,7 +156,7 @@ An employee of Company A calls `GET /api/v1/vehicles/<vehicleId_from_company_B>/
 
 ## Frontend Scan Results
 
-A full scan of all four frontend applications (dashboard, admin, marketplace, public-site) was performed. No vulnerabilities above the reporting threshold (confidence ≥ 8/10) were confirmed.
+A full scan of all four frontend applications (dashboard, admin, storefront, public-site) was performed. No vulnerabilities above the reporting threshold (confidence ≥ 8/10) were confirmed.
 
 ### Hardening Recommendations (not vulnerabilities)
 
@@ -164,7 +164,7 @@ Two items were identified as best-practice improvements:
 
 1. **Admin auth-redirect `next` param** (`apps/admin/src/app/auth-redirect/page.tsx`) — Validate the `next` query parameter is a relative path (starts with `/`, does not contain `://`) before passing it to `router.replace`. The router itself does not perform cross-origin navigation, but defense-in-depth is recommended.
 
-2. **`postMessage` wildcard origin + missing `frame-ancestors` CSP** (`apps/dashboard/src/app/sign-in/[[...sign-in]]/SignInPageClient.tsx`, `apps/dashboard/next.config.js`) — Replace `targetOrigin: '*'` with the marketplace origin, and add `Content-Security-Policy: frame-ancestors 'self' <marketplace-origin>` to prevent the sign-in page from being embeddable by arbitrary third-party domains.
+2. **`postMessage` wildcard origin + missing `frame-ancestors` CSP** (`apps/dashboard/src/app/sign-in/[[...sign-in]]/SignInPageClient.tsx`, `apps/dashboard/next.config.js`) — Replace `targetOrigin: '*'` with the storefront origin, and add `Content-Security-Policy: frame-ancestors 'self' <storefront-origin>` to prevent the sign-in page from being embeddable by arbitrary third-party domains.
 
 ---
 

docs/project-design/api-routes.md

@@ -68,7 +68,7 @@ This is the default for dashboard/company management routes.
 
 ### Subscription Guard
 
-`requireSubscription` blocks company routes when the company status is `PENDING` or `SUSPENDED`. Public site and marketplace routes are intentionally not behind this guard.
+`requireSubscription` blocks company routes when the company status is `PENDING` or `SUSPENDED`. Public site and storefront routes are intentionally not behind this guard.
 
 ### Role-Based Access Control
 
@@ -90,7 +90,7 @@ Admin roles are hierarchical:
 
 `requireRenterAuth` validates a Bearer token with `type === "renter"` and attaches `req.renterId`.
 
-`optionalRenterAuth` is used on marketplace routes so public reads still work without a token.
+`optionalRenterAuth` is used on storefront routes so public reads still work without a token.
 
 ### API Key
 
@@ -136,7 +136,7 @@ The table below describes the current route groups mounted in `app.ts`.
 | `/api/v1/auth/employee` | Public plus employee JWT | Employee login, password reset, profile, language | Dashboard/staff authentication path |
 | `/api/v1/auth/renter` | Renter JWT for profile routes | Renter profile and push token | `signup` and `login` are currently disabled in this codebase |
 | `/api/v1/admin` | Admin JWT | Platform operations | Includes company admin, billing, subscriptions, pricing, audit, and admin-user management |
-| `/api/v1/marketplace` | Public, optional renter JWT | Marketplace discovery and reservation intake | Designed for discovery and lead capture across companies |
+| `/api/v1/storefront` | Public, optional renter JWT | Storefront discovery and reservation intake | Designed for discovery and lead capture across companies |
 | `/api/v1/site` | Public | White-label company site APIs | Drives each company-branded booking site |
 | `/api/v1/subscriptions` | Mixed | Plan listing, webhooks, subscription lifecycle | Public, webhook, and authenticated sub-routers share the same prefix |
 | `/api/v1/vehicles` | Employee JWT + tenant + subscription | Fleet management | Includes photos, status, calendar blocks, maintenance, and availability |
@@ -228,17 +228,17 @@ Customers are company-scoped CRM records, even when a renter identity also exist
 
 This is intentionally separate from renter identity because one renter may interact with multiple companies while each company still needs its own operational customer record.
 
-### Marketplace and public site
+### Storefront and public site
 
 The public surface is split in two modules on purpose.
 
-`marketplace` is the cross-company discovery layer:
+`storefront` is the cross-company discovery layer:
 
 - featured/public offers
-- marketplace cities
+- storefront cities
 - listed companies
 - vehicle search
-- marketplace reservation intake
+- storefront reservation intake
 - review submission by token
 - company public pages under `/:slug`
 
@@ -318,7 +318,7 @@ The admin router is broad because it covers platform operations across multiple
 - billing account and billing invoice operations
 - pricing config, plan features, and promotions
 - subscription overrides and extensions
-- marketplace homepage configuration
+- storefront homepage configuration
 
 This is the only route group allowed to work across tenants.
 

docs/project-design/schema.md

@@ -243,7 +243,7 @@ Purpose:
 - public contact and social metadata
 - default locale and currency
 - company-owned payment provider settings for renter payments
-- marketplace visibility and rating
+- storefront visibility and rating
 - homepage/menu JSON configuration
 
 Important uniqueness: