Sandbox access-rule decisions: delete/rename cascade, parent-admin floor

Context

Two open access-rule questions left over from PR #4763 (Sandboxes: scope visibility, tighten merge gate, drop superuser bypass). The merge-gate and superuser-bypass items in the original list shipped with that PR; these two remain.

The two open questions

1. Delete/rename cascade

Today: A user can delete or rename a sandbox if they are owner/admin of the sandbox itself, or owner/admin of the absolute workspace root. The "root cascade" lets a workspace owner manage any sandbox underneath.

Question: keep the cascade, or drop it so only direct admin/owner of the sandbox can act?

2. Parent-admin floor

Today: A user who is admin or owner on any parent project cannot be removed from a descendant sandbox, even by the sandbox's own owner. The floor is enforced both at the UI (Remove button disabled) and at the data layer (Projects.delete_project_user! raises).

Question: keep the floor, or drop it so a sandbox owner has full control over the sandbox's membership?

Why they're coupled

Both are "the workspace owner has special powers over descendant sandboxes" rules. Dropping the cascade makes the floor a one-off exception with no underlying rationale; keeping the cascade keeps both rules consistent with each other.

Start by reviewing PR #4763 and the current UI Remove-button behavior and Projects.delete_project_user! data-layer guard described here. Resolve whether both workspace-owner powers should be kept or removed together, then document the decision and update the corresponding UI and data-layer behavior.