parity(api,apps): security hotfix stage 2 - real customer sessions, close IDOR

Stage 1 narrowed GET /customers but did not close the leak: the response still
carried every customer id, and /customers/:id, /:id/orders and
/:id/ledger-entries were still public, so the full customer book was still two
requests away. The user caught this. Stage 2 deletes the id-bearing surface.

Customer JWT, separate from the admin one (T1):
  - new src/modules/customer-auth/ with its own passport strategy,
    CustomerJwtGuard, @CustomerAuth() and @CurrentCustomer()
  - signed with JWT_CUSTOMER_SECRET, and every token carries typ:'customer'
    which the strategy verifies; both checks are present deliberately
  - customer state re-read per request, so deactivating takes effect at once
  - mirrors the reference's own split: auth:api vs auth('api-customer')

Real OTP (D6), porting ApiMobileController::userAuth/userVerfiy (:39-64):
  - new CustomerOtp table, additive migration, nothing existing touched
  - parity behaviour: rand(1000,9999), active-customer filter, faTOen digit
    normalisation on both number and code, rejection on mismatch
  - approved improvements over the reference: bcrypt-hashed code, 2-minute
    expiry, 5 attempts then lockout, single use, send throttle (60s per
    number, 5/number and 20/IP per 10 min), and no number enumeration

Routes removed, replaced by token-derived equivalents:
  GET customers, customers/:id, /:id/orders, /:id/ledger-entries
    -> GET customer/me, customer/me/orders, customer/me/ledger-entries
No route accepts a customer id any more, so the IDOR is closed structurally
rather than by a check. The admin panel was unaffected (admin/customers-omde/*).

Both apps migrated in the same commit per the v1/v2 parity rule: token-based
session store, Bearer header, 401 -> clear session and route to login, real
two-step OTP login. Each app keeps its own markup and styling; only logic moved.

Tests: auth-smoke.sh extended with the stage-2 assertions, 46 passed 0 failed
against a live server. jest installed dev-only (user-approved) so pnpm test
works for the first time: 7 passed covering faToEn, which moved to its own
digits.ts to be testable without booting Nest. Typecheck clean on api,
user-app and user-app-v2; both apps build.

[ref: henza_server ApiMobileController.php:39-78]

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

apps/api/src/modules/customers/customers.controller.ts

@@ -1,49 +0,0 @@
-import { Controller, Get, Param } from '@nestjs/common';
-import { CustomersService } from './customers.service';
-import { Public } from '../auth/guards';
-
-/**
- * Customer-facing reads.
- *
- * Still `@Public()` because the target has no customer session yet — every one
- * of these is called with `session.customerId` straight from the browser
- * (DashboardView / ProfileView / OrdersView / TransactionsView), so any caller
- * who guesses or harvests an id can read that customer's data. That is a
- * textbook IDOR and it is what stage 2 of the security hotfix closes, by
- * deriving the customer from a `customer-jwt` token instead of the URL
- * (decision T1 in docs/parity/DECISIONS.md). The reference did exactly that
- * via its `api-customer` guard.
- *
- * What stage 1 already fixed: `list()` no longer returns the full customer
- * record — see LOGIN_LOOKUP_SELECT in customers.service.ts (SEC-08).
- */
-@Public() // pre-existing unauthenticated endpoint; closed in hotfix stage 2
-@Controller('customers')
-export class CustomersController {
-  constructor(private readonly customers: CustomersService) {}
-
-  /**
-   * Login lookup only. Returns id/mobile/isActive/isArchived and nothing else;
-   * both apps' LoginView downloads this and matches the phone in the browser.
-   * Removed entirely in stage 2 once OTP verify returns the one customer.
-   */
-  @Get()
-  list() {
-    return this.customers.list();
-  }
-
-  @Get(':id')
-  get(@Param('id') id: string) {
-    return this.customers.getOrThrow(id);
-  }
-
-  @Get(':id/orders')
-  getOrders(@Param('id') id: string) {
-    return this.customers.getOrders(id);
-  }
-
-  @Get(':id/ledger-entries')
-  getLedgerEntries(@Param('id') id: string) {
-    return this.customers.getLedgerEntries(id);
-  }
-}

apps/api/src/modules/customers/customers.module.ts

@@ -1,9 +1,21 @@
 import { Module } from '@nestjs/common';
 import { CustomersService } from './customers.service';
-import { CustomersController } from './customers.controller';
 
+/**
+ * Customer reads, exposed only through CustomerAuthController's token-derived
+ * /customer/me* routes.
+ *
+ * CustomersController used to live here and served GET /customers,
+ * /customers/:id, /customers/:id/orders and /customers/:id/ledger-entries, all
+ * unauthenticated. The list handed any visitor every customer's national code,
+ * debts, credit limit and identity-document URLs, and the :id routes let anyone
+ * holding an id read that customer's profile, orders and ledger — so narrowing
+ * the list alone did not close it. The whole controller is gone; the service
+ * stays and is now only reachable behind a customer token.
+ *
+ * See SEC-08 in docs/parity/ISSUES.md.
+ */
 @Module({
-  controllers: [CustomersController],
   providers: [CustomersService],
   exports: [CustomersService],
 })

apps/api/src/modules/customers/customers.service.ts

@@ -24,30 +24,15 @@ const PUBLIC_CUSTOMER_SELECT = {
 } satisfies Prisma.CustomerSelect;
 
 /**
- * The only fields `GET /customers` may expose.
+ * Every method here is reached only through CustomerAuthController's
+ * token-derived /customer/me* routes, which pass the id from the JWT.
  *
- * That route is unauthenticated because both user apps' login screens download
- * the list and match the phone number in the browser. With the full select
- * above, an anonymous caller got the entire customer book: every national ID
- * number, every debt and credit limit, and the URLs of every identity-document
- * scan. Logged as SEC-08 in docs/parity/ISSUES.md.
- *
- * The reference never allowed this — its login was
- * POST userAuth (SMS) -> POST userVerfiy, and the server returned exactly ONE
- * customer after the code matched (henza_server ApiMobileController.php:39-78).
- *
- * Stage 2 of the security hotfix restores that flow and removes this route from
- * the public surface entirely. Until then these four fields are what the login
- * screens actually read (LoginView.vue:131-133 matches on mobile/isActive/
- * isArchived, then calls session.login(id, mobile)) — nothing more.
+ * There used to be a `list()` returning every active customer, because the two
+ * apps' login screens downloaded it and matched the phone number in the
+ * browser. It is gone: the login lookup now happens server-side inside
+ * CustomerAuthService.requestOtp, which is what the reference did
+ * (henza_server ApiMobileController.php:39-49). See SEC-08.
  */
-const LOGIN_LOOKUP_SELECT = {
-  id: true,
-  mobile: true,
-  isActive: true,
-  isArchived: true,
-} satisfies Prisma.CustomerSelect;
-
 @Injectable()
 export class CustomersService {
   constructor(private readonly prisma: PrismaService) {}
@@ -61,21 +46,6 @@ export class CustomersService {
     return customer;
   }
 
-  // Ported from legacy henza_server's WebApp\AuthController::userAuth() /
-  // ApiMobileController::userAuth(), both of which query
-  // Customer::active()->where('is_archive', 0) — an inactive or archived
-  // customer cannot authenticate in the customer-facing app. This endpoint is
-  // that same lookup surface for the user-app login flow (client-side match
-  // on `mobile`), so it must apply the same two filters, or a
-  // deactivated/archived customer would still be able to log in.
-  list() {
-    return this.prisma.customer.findMany({
-      where: { isActive: true, isArchived: false },
-      select: LOGIN_LOOKUP_SELECT,
-      orderBy: { createdAt: 'desc' },
-    });
-  }
-
   getOrders(customerId: string) {
     return this.prisma.order.findMany({
       where: { customerId },