fix(authz): invalidate role cache on change

src/application/services/drive_management_service.rs

@@ -249,6 +249,20 @@ impl DriveManagementService {
             .set_role(caller_id, subject, role, resource, expires_at)
             .await?;
 
+        // Drop the entire drive-role cache for this drive so the new
+        // grant is visible on the very next `check` — without this, a
+        // caller that gets Owner via `POST /api/drives/{id}/members`
+        // then immediately acts on drive content (WebDAV cross-drive
+        // MOVE, admin-driven cleanup, drive management) hits the
+        // stale "no role for this subject on this drive" entry
+        // seeded at some earlier `check`. TTL rescues eventually,
+        // but the storage_cleanup_check.sh drain pattern hits this
+        // race within a single test-second and fails on `authz.denied`
+        // for admin's cascade to files inside.
+        self.authz
+            .invalidate_drive_role_cache_for_drive(drive_id)
+            .await;
+
         // D6 §11: canonical `drive.member_added` audit event covers
         // every successful membership write (add + role-refresh, since
         // the underlying `set_role` is UPSERT — distinguishing the two
@@ -312,6 +326,15 @@ impl DriveManagementService {
 
         self.authz.clear_role(subject, resource).await?;
 
+        // Mirror of `set_member_role`'s cache invalidation: after
+        // clearing a role we MUST drop the `drive_role_cache` entries
+        // targeting this drive, otherwise the just-removed subject's
+        // former role stays visible until TTL expires. Same anti-drift
+        // reason as the sibling add path above.
+        self.authz
+            .invalidate_drive_role_cache_for_drive(drive_id)
+            .await;
+
         // D6 §11: canonical `drive.member_removed` audit event covers
         // every successful removal (owner-driven or admin bypass).
         // `via_admin` replaces the separate

src/application/services/file_management_service.rs

@@ -380,6 +380,20 @@ impl FileManagementUseCase for FileManagementService {
 
         let dto = self.move_file(file_id, folder_id, caller_id).await?;
 
+        // Cross-drive move invalidates the file's `owner_cache` entry
+        // in the authz engine — the cache assumed drive_id stability
+        // that no longer holds. Without this call the drive-role
+        // precheck at `check_inner` steers to the (stale) source
+        // drive and legitimate Delete/Update by a destination-drive
+        // role-holder returns 404 for up to the cache TTL.
+        if cross_drive.is_some()
+            && let Ok(file_uuid) = Uuid::parse_str(file_id)
+        {
+            self.authz
+                .invalidate_owner_cache_for_resource(Resource::File(file_uuid))
+                .await;
+        }
+
         // D6 §11 audit: emit only when the move actually crossed a
         // drive boundary. Same-drive moves are too noisy to audit at
         // info — operators care about the cross-drive case for

src/application/services/folder_service.rs

@@ -641,6 +641,17 @@ impl FolderUseCase for FolderService {
                 )
             })?;
 
+        // Cross-drive move flushes the authz engine's `owner_cache`
+        // — every descendant's cached `Resource → drive_id` mapping
+        // just got stale via the cascade trigger, and we don't (yet)
+        // walk the subtree to invalidate individually. Small perf
+        // cost (single JOIN per resource touched over the next
+        // minute) versus a stale-authz bug where destination-drive
+        // Owner cascades don't apply to moved content.
+        if cross_drive.is_some() {
+            self.authz.invalidate_owner_cache_all().await;
+        }
+
         // D6 audit: only emit when the move crossed a drive boundary.
         // The cascade trigger has already propagated drive_id to the
         // subtree at this point (see migration