fix: Fix scale rule cache eviction by using rule ids(#6972)

[juicewcode]

Fixes #6972
Fixes #6623
Fix scale rule cache consistency for create, update, and delete operations.

ScaleRuleCache stores rules in a map keyed by metricName, while database operations identify rules by their primary key id. This difference could cause cached rules to become inconsistent with the database:

• A newly created rule could be cached with a different id from the database
  record.
• Renaming a rule could leave the old metric-name entry in the cache.
• Deleting a rule by id could fail to remove its cache entry because the id was
  incorrectly treated as a metric-name key.

##Changes

• Cache the same ScaleRuleDO instance that is inserted into the database,
  preserving the database-generated id.
• Remove the old metric-name cache entry when a rule is renamed.
• Add removeRulesByIdsFromCache to find cached rules by their database ids and remove them using their metric-name map keys.
• Update ScaleRuleServiceImpl#delete to use removeRulesByIdsFromCache.

These changes ensure that the in-memory scale-rule cache remains consistent with the database after rules are created, renamed, or deleted.

Make sure that:

• You have read the contribution guidelines.
• You submit test cases (unit or integration tests) that back your changes.
• Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true.

[Aias00]

This delete-by-ID eviction still depends on the cached rule ID matching the database row ID, but this PR is based on master, where ScaleRuleServiceImpl#create still inserts one ScaleRuleDO and then caches a second ScaleRuleDO built from the blank-id DTO. ScaleRuleDO.buildScaleRuleDO generates a fresh UUID when the DTO id is empty, so rules created through the service can still have a cached id that differs from the DB id being deleted. Could you include the create-side cache fix here, or base this after the fix from #6973, so delete-by-ID eviction can actually find newly created cached rules?

[juicewcode]

This delete-by-ID eviction still depends on the cached rule ID matching the database row ID, but this PR is based on master, where ScaleRuleServiceImpl#create still inserts one ScaleRuleDO and then caches a second ScaleRuleDO built from the blank-id DTO. ScaleRuleDO.buildScaleRuleDO generates a fresh UUID when the DTO id is empty, so rules created through the service can still have a cached id that differs from the DB id being deleted. Could you include the create-side cache fix here, or base this after the fix from #6973, so delete-by-ID eviction can actually find newly created cached rules?

This change is based on the cache consistency fix from PR #6973 .

The following cache consistency issues are addressed:

• Newly created rules are cached using the same ScaleRuleDO instance that was inserted into the database, ensuring that
  the cached rule id matches the database id.
• For deletion, cached rules are located by their database primary keys and removed using their metric-name cache keys.
• When a rule's metricName is changed, the previous metric-name cache entry is removed before the updated rule is cached.

The PR body has also been updated to reflect these changes and the problems they resolve.