feat: extract auth into @marketplaces/auth package, add backoffice admin provisioning spec

- ADR-0001: decision to extract auth/payment into shared @marketplaces/* packages
- Scaffold packages/auth, packages/payment; @marketplaces/auth now holds the real
  telegram (customer+admin QR/session) and ed25519 (future admin challenge/response)
  auth implementation, pushed to sources.vitanova.network/sdarbinyan/vitanovaPackages
- Rewire ~30 call sites to import from @marketplaces/auth; delete migrated originals
  from core/auth, core/admin-auth, services/, models/
- Replace environment coupling with AUTH_API_URL/TELEGRAM_BOT_USERNAME injection
  tokens and isDevMode(); wired as file:packages/auth pending registry publish
- Add TRACK-S §8: bootstrap per-marketplace admin login + marketplace-scoped
  sub-admin invite/role endpoints
- Build, arch:check:boundaries, and full test suite (103/103) all green

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

docs/backend/TRACK-S-SECURITY-RBAC-CONTRACT.md

@@ -75,7 +75,35 @@ Required before: bank/payment detail changes (Phase 5 §5), production launch (P
 
 Customer/seller PII is exposed only to roles that need it for their scope (e.g. `FINANCE_VIEWER` sees payout totals, not raw bank account numbers unless `FINANCE_MANAGER`+). Export endpoints (`GET .../export`) are themselves audit-logged actions per §3.
 
-## 8. What the frontend will start doing once this ships
+## 8. Initial admin provisioning & self-service admin management
+
+Each marketplace ships with one bootstrap `MARKETPLACE_ADMIN` account, seeded at provisioning time (Phase 9 launch step):
+
+- `login` = marketplace slug (`projectName`)
+- `password` = `{projectName}2026$`, flagged `mustChangePassword: true`
+- Login succeeds but every non-auth request 403s with `PASSWORD_CHANGE_REQUIRED` until password is changed.
+
+```
+POST /api/identity/v1/session/change-password   { currentPassword, newPassword }
+```
+
+A `MARKETPLACE_ADMIN` can then provision sub-admins scoped to their own marketplace only — mirrors the seller-team invite pattern in [Phase 5](PHASE-5-SELLER-PORTAL-CONTRACT.md) (`POST /api/seller/v1/team/invite`):
+
+```
+POST /api/admin/v2/team/invite   { email, role: MarketplaceRole, marketplaceId }
+GET  /api/admin/v2/team?marketplaceId=
+PATCH /api/admin/v2/team/{userId}   { role }
+DELETE /api/admin/v2/team/{userId}
+```
+
+Invariants:
+- `role` must be one of the `MarketplaceRole` set (§1) — never `PlatformRole`. Backend rejects any attempt to grant a platform-scope role through this endpoint (`403 SCOPE_ESCALATION_DENIED`).
+- `marketplaceId` is forced server-side to the caller's own tenant scope — request body value is ignored/validated, never trusted.
+- Every invite/role-change/removal is an audit-logged action (§3, `action: 'admin_team.invited' | 'admin_team.role_changed' | 'admin_team.removed'`).
+- Role grants at `MARKETPLACE_ADMIN` level require step-up auth (§6).
+- Invited admins get their own credentials (email + set-password flow), not the shared bootstrap login — the bootstrap account is for first login only and should be rotated/retired once real admins exist.
+
+## 9. What the frontend will start doing once this ships
 
 - Route guards and action-level permission checks across the entire backoffice — currently none exist.
 - Backoffice **Audit & Security** section (missing from admin nav today): role changes, sensitive actions, login/security events, exports.