[BUG] RoleServiceImpl.delete has no cascade to permission/user_role and no guard against deleting the super role

- severity: High
- files: `shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/RoleServiceImpl.java:126-133`
- description: `delete` only calls `roleMapper.delete(ids)`. It never removes `permission` rows whose `object_id` is the deleted role id (`permission.deleteByObjectIds` exists but is unused here) nor `user_role` rows whose `role_id` is deleted. Additionally, `role.selectById` filters `role_name != 'super'` but `selectByIds` (used at line 128) and `delete` do NOT, so the service can delete the `super` role.
- impact: Orphaned `permission` and `user_role` rows persist after role deletion, corrupting the permission graph; ability to delete the super role breaks admin access entirely.
- suggested_fix: In `RoleServiceImpl.delete`, reject ids whose role_name is 'super' (mirror `selectById`'s guard), then call `permissionMapper.deleteByObjectIds(ids)` and `userRoleMapper` delete-by-role-id before `roleMapper.delete`. Wrap in `@Transactional`.
- confidence: High
- related_existing: none.

---
_Identified during the 2026-08-02 deep re-scan; full list in [`docs/scan2-2026-08-02/00-consolidated-critical-high.md`](docs/scan2-2026-08-02/00-consolidated-critical-high.md)._

Start in shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/RoleServiceImpl.java:126-133 and compare delete with selectById's super-role guard. Inspect permissionMapper.deleteByObjectIds and the userRoleMapper deletion entry point before checking the transaction boundary. Done means deleting roles removes related permission and user_role rows, rejects the super role, and preserves admin access.

Written by the indexing model from the issue text.