parity(apps+api): complete_profile in both apps [ref: henza_server Major/CustomerController::complete]

Ports "تکمیل پروفایل" end to end (D22).

API
- POST customer/me/complete-profile — three required document ids, the
  customer taken from the token, verification step set to the reference's
  LIVE value (approved outright; its `= 1` line is commented out at :83 in
  favour of `= 2` at :85). Both SMS messages byte-identical and non-blocking
  per D20.
- POST customer/me/documents — the reference let the app upload through the
  same file/create the admin used, inside its auth:api-customer group
  (routes/api.php:95); the target's copy is admin-guarded, so the page could
  not have uploaded at all. Reuses AdminUploadsService unchanged, so both
  paths share one size limit, MIME whitelist and naming scheme (UPL-01).
- PROFILE_ADMIN_MOBILES replaces the reference's four hardcoded personal
  numbers; blank means nobody is notified and the upload still succeeds.

Three reference behaviours deliberately NOT ported, all in ISSUES.md:
- SEC-14: `$customer->update($request->all())` mass-assigned the whole request
  body, letting the app write its own credit limit, making charge, gold debt,
  active flag or mobile. Replaced with a three-field whitelist.
- SEC-15: four real personal mobiles hardcoded in the source.
- APP-03: refresh()'s unterminated setInterval page reload.

Apps (both, template+script byte-identical, per-app styling only)
- CompleteProfileView + SingleImageUploader
- route /complete_profile, redirecting home once the documents are in, as the
  reference's guard did (router/index.ts:266)
- the entry point on the profile screen, shown only while they are missing
  (profile.vue:96-102)

Also (D23): JWT_CUSTOMER_SECRET now warns loudly at boot when unset. It falls
back to JWT_SECRET, which signs app and admin tokens with the same key and
leaves the `typ` check as the only barrier — and an expert's app token carries
their AdminUser id in `sub`. Warn rather than refuse to boot (D19, lowest
risk); DELIVERY.md lists it as the first pre-release step (REL-03).

Verified: build 5/5 · jest 45/45 · complete-profile 38/38 (new) ·
expert login 36/36 · apps smoke 43/43 · admin smoke 43/43 ·
B2B scan 34 ok/0 broken · typecheck clean on all four apps.

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

apps/api/src/main.ts

@@ -22,6 +22,33 @@ async function bootstrap() {
   // no longer stops the boot; messages are logged instead of sent.
   assertSmsConfigured();
 
+  // A missing JWT_CUSTOMER_SECRET is not a cosmetic default: customerJwtSecret()
+  // falls back to JWT_SECRET, so admin and app tokens end up signed with the
+  // SAME key. The `typ` check in JwtStrategy is then the only thing keeping an
+  // app token off the admin routes — one guard instead of two independent ones,
+  // and a sales expert's app token carries their AdminUser id in `sub`. Warn as
+  // loudly as the master-code banner rather than fail the boot, so a running
+  // deployment that has not set it yet still starts.
+  if (!process.env.JWT_CUSTOMER_SECRET?.trim()) {
+    const sharedWithAdmin = Boolean(process.env.JWT_SECRET?.trim());
+    // eslint-disable-next-line no-console
+    console.warn(
+      '\n' +
+        '='.repeat(72) +
+        '\n  ⚠  JWT_CUSTOMER_SECRET تنظیم نشده است\n' +
+        '  ⚠  JWT_CUSTOMER_SECRET IS NOT SET.\n' +
+        (sharedWithAdmin
+          ? '  ⚠  Customer/expert app tokens are being signed with JWT_SECRET,\n' +
+            '  ⚠  the SAME key as admin tokens. The two token realms are no\n' +
+            '  ⚠  longer cryptographically separated.\n'
+          : '  ⚠  Neither JWT_SECRET nor JWT_CUSTOMER_SECRET is set, so app\n' +
+            '  ⚠  tokens are signed with a well-known development string.\n') +
+        '  ⚠  Set JWT_CUSTOMER_SECRET to a distinct random value before release.\n' +
+        '='.repeat(72) +
+        '\n',
+    );
+  }
+
   // D20 — a loud, unmissable banner whenever the delivery bypass is armed, so
   // it cannot reach the real release unnoticed.
   if (masterOtpEnabled()) {