Revert "PHP Rebuild"

This reverts commit 2ef3654841.

prisma/migrations/20260804202300_phase10_backfill_owner_permissions/migration.sql

@@ -0,0 +1,31 @@
+-- Backfill MANAGE_MEDIA_LIBRARY and MANAGE_REVIEWS (added in Phase 9)
+-- onto every role that already holds MANAGE_STAFF — the app's existing
+-- definition of "owner" (see src/services/staff/staff.service.ts's
+-- countOtherActiveManagers, "A role holding MANAGE_STAFF is this app's
+-- definition of 'an owner'"). syncRolePermissions() only ever runs at
+-- install/seed time, so any business installed before Phase 9 has its
+-- Owner role stuck on the old 15-permission set — confirmed by reading
+-- the actual RolePermission rows on a real installed business before
+-- writing this migration.
+--
+-- This is what silently made /owner/settings/reviews redirect away
+-- (hasPermission(..., MANAGE_REVIEWS) failing, redirecting to /staff,
+-- which then renders the barber calendar — looking exactly like
+-- "Reviews opens Calendar") and made Media Manager deletes silently fail
+-- (MANAGE_MEDIA_LIBRARY). Not a routing bug — a missing data backfill.
+--
+-- Idempotent: a fresh install's Owner role already has both permissions
+-- from syncRolePermissions() at install time, and INSERT IGNORE plus the
+-- existing @@unique([roleId, permission]) constraint make re-running
+-- this migration (or running it against an already-correct database)
+-- a safe no-op.
+
+INSERT IGNORE INTO `RolePermission` (`id`, `roleId`, `permission`)
+SELECT UUID(), owner.`roleId`, 'MANAGE_MEDIA_LIBRARY'
+FROM `RolePermission` owner
+WHERE owner.`permission` = 'MANAGE_STAFF';
+
+INSERT IGNORE INTO `RolePermission` (`id`, `roleId`, `permission`)
+SELECT UUID(), owner.`roleId`, 'MANAGE_REVIEWS'
+FROM `RolePermission` owner
+WHERE owner.`permission` = 'MANAGE_STAFF';