Overview

This PR is a small, frontend-only cache-invalidation fix. It introduces two new broader React Query keys — secretApprovalRequestKeys.listAllForProject({ projectId }) and accessApprovalKeys.getAccessApprovalRequestsAllForProject(projectSlug) — which are strict prefixes of the existing narrower list keys. The new project-scoped keys are then invalidated from approval-request mutations, secret mutations (create/update/delete/batch/move/commit), ActionBar.handleSaveFolderImport, and SecretListView.handleSaveSecret/handleSecretDelete. The intent is to ensure that approval-request lists refresh regardless of which narrower filter key the UI had subscribed under.

Security risks

None meaningful. These are client-side React Query cache invalidations — no auth, crypto, permissions, or server-side logic is touched. Request bodies and API surfaces are unchanged. The prefix-based invalidation is wider than before but still scoped to the current project.

Level of scrutiny

Low. The changes are mechanical and repetitive: each modified callsite adds a single queryClient.invalidateQueries({ queryKey: ...listAllForProject({ projectId }) }) alongside existing invalidations, and three access-request mutations are retargeted from the narrow getAccessApprovalRequests(projectSlug, envSlug, requestedBy, bypassReason) key to the new broader getAccessApprovalRequestsAllForProject(projectSlug) key. Because React Query uses prefix matching for invalidation, the broader key still covers any active narrower subscriptions, so behavior is strictly a superset of the previous behavior.

Other factors

The inline comment flags a nit: useReviewAccessRequest's variables type still declares envSlug?/requestedBy? and the ReviewAccessModal caller still passes them, even though the mutation body and onSuccess no longer consume those fields. This is dead code, not a functional defect — prefix-match invalidation still works correctly and the request body to the backend is unchanged. Not worth blocking on.