[BUG] DataPermissionServiceImpl.createSelector is not transactional

## Description
`createSelector` inserts the SELECTOR permission row, then collects all rules for that selector and inserts RULE permission rows in a single `insertBatch`. The method has **no** `@Transactional`. If the batch insert throws (duplicate key, constraint, DB error), the selector permission row remains committed. The sibling methods `createRule` (line 227) and `deleteSelector` (line 139) are both `@Transactional(rollbackFor = Exception.class)`.

## Location
```
shenyu-admin/.../service/impl/DataPermissionServiceImpl.java:111-129
createRule at :227, deleteSelector at :139
```

## Impact
Orphan selector permission with no/partial rule permissions; a user appears to have selector access but no rule access.

## Suggested fix
Add `@Transactional(rollbackFor = Exception.class)` to `createSelector`.

## Related existing issue(s)
None

_Identified during the 2026-08-02 audit; full list in [`docs/issue-candidates-2026-08-02.md`](docs/issue-candidates-2026-08-02.md)._

Open shenyu-admin/.../service/impl/DataPermissionServiceImpl.java and inspect createSelector at lines 111-129 alongside the @Transactional annotations on deleteSelector at line 139 and createRule at line 227. Add the matching transaction behavior to createSelector and verify that a failed rule batch does not leave the selector permission row committed.

Written by the indexing model from the issue text.