SECURITY REVIEW — Deployment gates

Runtime dependency audit:
- `npm audit --omit=dev` previously returned zero vulnerabilities after upgrading Prisma to v7. Re-run this command before each release.

Development toolchain:
- `next` and `eslint-config-next` have been updated together from 16.4.0 to 16.4.2. Lint, typecheck, all 132 tests, and the production build pass on this version.
- The current full `npm audit` still reports five HIGH package findings in the ESLint/Next development toolchain: `eslint-config-next` -> `@next/eslint-plugin-next` -> `fast-glob` -> `micromatch` -> `braces`. These are the transitive chain for one underlying advisory, not five independent vulnerability advisories.
- The root advisory is [GHSA-vfj7-8cjw-p6xm](https://github.com/advisories/GHSA-vfj7-8cjw-p6xm), a stack-exhaustion denial of service for deeply nested `braces` patterns (CVSS 7.5; affected through `braces` 3.0.3 and earlier). The current published `braces` version is still 3.0.3, so there is no fixed upstream version to pin.
- The audit's suggested automatic fix downgraded `eslint-config-next` to 14.2.35, which is incompatible with the project's Next.js 16 flat-config setup.
- Pinning the latest published transitive versions (`fast-glob` 3.3.3, `micromatch` 4.0.8, and `braces` 3.0.3) did not remove the advisories. Those ineffective overrides have been removed from `package.json`.
- No force downgrade or ineffective override was applied. `npm audit --omit=dev` reports zero vulnerabilities; the remaining finding is development-tooling-only. Keep it as an explicit deployment exception until a fixed `braces` release and compatible Next/ESLint dependency chain are available, then re-audit.

Customer account recovery:
- Legacy accounts without a verified email are intentionally not attached to an email account using phone number or the old customer code alone.
- Recovery requires an independent proof of ownership (for example, a one-time code sent to the already stored phone number or an audited staff verification process). Until such a method is selected and implemented, those legacy orders/vouchers remain unavailable through cross-device history.

Staging requirements:
- The application now targets MariaDB/MySQL only. The local MySQL server at `127.0.0.1:3306` was unreachable during setup (Prisma P1001); the new MySQL baseline has not been applied to any database.
- The previous PostgreSQL database still has five pending migrations (`20261015000000_plan_resource_limits`, `20261015160000_order_safety_billing_grace`, `20261015170000_email_order_history`, `20261015180000_phone_customer_loyalty`, and `20261017200000_customer_email_verification`). It is no longer selected by the app, has not been modified or migrated, and its data has not been copied to MySQL.
- SMTP connectivity/authentication was verified previously, but no email was sent. End-to-end delivery and customer email verification remain untested.
- Apply database migrations only in an explicitly provisioned staging environment after backup/restore and schema validation.
- Verify SMTP connectivity and perform a delivery test only to an authorized test mailbox.
- Do not test customer email verification using real customer addresses.