Enforce consistent deletion permissions and state rules across single and batch APIs

[zackcl]

Blocked by #3323, which adds the batch deletion endpoints this issue covers. Also, the load tests might need to be updated after this change is applied.

Problem

Deletion permissions and state restrictions are enforced in the UI but not by the single and batch deletion APIs.

For example, an authenticated Reader can directly request deletion, and an authenticated caller can delete an Enabled feature flag even though the UI hides Delete.

Scope

• Apply the same role permissions to single and batch deletion of experiments, feature flags, and segments.
• Define and enforce consistent state/usage restrictions based on the agreed UI rules.
• Verify that rejected deletions leave the target unchanged and that batch results clearly report the affected items.
• Update the load-testing setup to use an authorized account and make test entities deletable before cleanup.

Coordinate the API behavior change with existing callers. Request-size limits and timeout policies are outside this issue.

Rules to enforce

Roles, from the frontend permission map in auth.service.ts:

Role	Experiments	Feature Flags	Segments
ADMIN	delete	delete	delete
CREATOR	delete	delete	delete
USER_MANAGER	no	no	delete
READER	no	no	no

State and usage:

• Experiments: deletable in Draft, Inactive, Completed (including experiments stored as Cancelled) and Archived. Not deletable in Running, Paused, Preview or Scheduled.
• Feature flags: not deletable while Enabled.
• Segments: not deletable while Used. Global-exclude segments are not offered for deletion.

Implementation notes

• DELETE /segments/:segmentId does not currently receive @CurrentUser(), so role checks there need the parameter added.
• DeletionRepository.findForDeletion() locks the row but selects only id. Evaluating state or usage rules needs more fields read under the same lock, not a separate unlocked read.
• DeletionReasonCode only has operational failure codes today, so a policy refusal would surface as delete_failed. Add codes that keep refusals distinguishable.
• Every @Authorized usage in the backend passes no roles today, so making authorizationChecker honor the roles argument would not change behavior for any existing route.
• The batch deletion integration tests currently assert that every role and every experiment state can delete through both routes. Those assertions need to be inverted as part of this work.

[Nakagawa-master]

I traced the current #3323 branch so this can land without single/batch drifting apart again.

The clean seam looks like a shared backend deletion policy evaluated after the target is loaded/locked but before any mutation, rather than guards duplicated in the three controllers.

Why that location matters on the current branch:

• single experiment delete can take the Mooclet branch in ExperimentController.delete() before ExperimentService.delete();
• batch delete goes through BatchDeleteService.deleteOne(), which already takes a pessimistic write lock via DeletionRepository.findForDeletion(...) before dispatching to experiment/flag/segment services;
• segment single delete currently does not even receive @CurrentUser();
• feature-flag and experiment service deletes currently mutate directly once a target is found.

So a controller-only fix can still leave Mooclet/batch/service callers with different rules.

A shape I would use is conceptually:

DeletionPolicyService.authorize({
  entity: 'experiments' | 'flags' | 'segments',
  target,          // enough current state/usage/type fields for the rule
  user,
}) -> allowed | { reasonCode }

Then:

1. single delete loads current target + evaluates the same policy before either local or Mooclet deletion;
2. batch delete evaluates it inside the existing per-item transaction, after the row lock and before mutationStarted = true;
3. rejected items return a policy result, not a generic execution failure;
4. no audit log, cache invalidation, Mooclet call, recompute, or delete runs for a rejected item.

The current DeletionRepository.findForDeletion() selects only id, so #3326 will need either:

• a policy-specific locked projection containing the required fields; or
• an entity-specific policy loader using the same transaction manager.

I would avoid authorizing from an unlocked pre-read and then deleting under a later lock; state can change between those two points.

Result vocabulary

It would also help to extend DeletionReasonCode so policy refusals remain distinguishable from operational failures, e.g.:

• role_forbidden
• state_not_deletable
• segment_in_use
• global_exclude_protected

Then a batch like [deletable, running, missing] can report each item truthfully rather than turning an expected policy refusal into delete_failed.

Regressions worth pinning

For both single and batch paths:

• READER deleting anything → refused, target unchanged;
• USER_MANAGER deleting experiment/flag → refused;
• USER_MANAGER deleting ordinary unused segment → allowed;
• experiment transitions from Draft to Running before locked policy check → refused;
• flag Enabled at locked check → refused;
• segment Used at locked check → refused;
• global-exclude segment → refused even for a role otherwise allowed;
• rejected deletion produces no delete audit event and no post-delete recompute/cache side effect;
• Mooclet-backed experiment follows the exact same role/state policy as a local experiment.

The important invariant is: UI visibility is guidance; the locked backend state plus current caller role is the authority. Single and batch should consume one policy, not merely happen to implement matching rules.