[BUG] ScaleRuleCache mutated before @Transactional commit → stale cache on rollback

- severity: Low-Medium
- files: `shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/ScaleRuleServiceImpl.java:96-99,108-115,124-131,140-146`; `shenyu-admin/src/main/java/org/apache/shenyu/admin/scale/monitor/subject/cache/ScaleRuleCache.java`
- description: `ScaleRuleServiceImpl.createOrUpdate` is `@Transactional` (line 96) and delegates to `create`/`update`/`delete`, each of which mutates `ScaleRuleCache` immediately after the mapper call but *inside* the still-open transaction. If the surrounding `@Transactional` rolls back after the cache mutation, the in-memory cache now holds a rule that was rolled back in DB (create/update) or has had a rule removed that still exists in DB (delete).
- impact: Cache/DB divergence on rollback → scaling decisions made against non-existent rules or missing newly-created rules.
- suggested_fix: Apply cache mutations in an `AFTER_COMMIT` phase.
- confidence: Low-Medium
- related_existing: none. Distinct from PERF-11 (unbounded caches) and from #6478 (wrong cache key on node-sync deletes).

---
_Identified during the 2026-08-02 deep re-scan; full list in [`docs/scan2-2026-08-02/06-medium-tiers.md`](docs/scan2-2026-08-02/06-medium-tiers.md)._

Start with ScaleRuleServiceImpl.createOrUpdate and its create, update, and delete methods at the cited lines, then read ScaleRuleCache to understand each mutation. Verify the transaction behavior around these entry points, including rollback scenarios. Done means cache changes occur only after a successful commit and the cache remains aligned with the database after rollback.

Written by the indexing model from the issue text.