fix: Fix scale rule cache entity inconsistency(#6623)

[juicewcode]

Fixes #6623

ScaleRuleServiceImpl#create and update build ScaleRuleDO twice.

For create operations without an ID, each call to buildScaleRuleDO generates a new UUID. Therefore, the entity stored
in the cache may have a different ID from the entity inserted into the database.
For update operations, rebuilding the entity can also produce a different dateUpdated timestamp.

Changes

• Reuse the original ScaleRuleDO after a successful create.
• Reuse the after entity after a successful update.

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]

Reusing after fixes the double-build inconsistency, but update still leaves a stale cache entry when metricName changes. ScaleRuleCache is keyed by metricName, and the update path only puts the updated rule under the new key; it never removes the old metric-name key for the same id. After renaming a rule, getAllRules() can therefore return both the old cached rule and the updated one until cache reload/restart. Could you load the existing rule before update and remove the old metric-name key when it differs from the new one before adding the updated rule?

[juicewcode]

Reusing after fixes the double-build inconsistency, but update still leaves a stale cache entry when metricName changes. ScaleRuleCache is keyed by metricName, and the update path only puts the updated rule under the new key; it never removes the old metric-name key for the same id. After renaming a rule, getAllRules() can therefore return both the old cached rule and the updated one until cache reload/restart. Could you load the existing rule before update and remove the old metric-name key when it differs from the new one before adding the updated rule?

PR #6975 is based on this cache consistency fix and additionally removes the stale cache entry when a rule's metricName
changes. It also includes ID-based cache eviction for deletion and preserves the database id when caching newly created
rules.

This PR can be closed in favor of PR #6975.