Description:

When a prebuilt rule with a missing base version is customized and then updated, reverting the customization incorrectly leaves the rule marked as customized instead of resetting is_customized to false.
Same can be observed when order of steps is inverted: Customize -> Revert changes -> Update the rule

The modified field is one of the fields covered by the scalar diff array (e.g., tags, references, new_terms_fields, threat_index).

Once the rule is updated, it will have a base version again, as we always store the most recent version of a rule in the package. This means that after the update, the rule should behave like any other rule with a base version and should follow the standard logic where reverting the customization resets is_customized=false.

Kibana/Elasticsearch Stack version:

VERSION: 9.1.0
BUILD: 84372
COMMIT: 636c06bcd35c4b563ba1742bee01b38636e61570

Functional Area (e.g. Endpoint management, timelines, resolver, etc.):

Prebuilt Rules Update

** Pre requisites:**

1. prebuiltRulesCustomizationEnabled flag is enabled
2. Prebuilt rules are available
3. Prebuilt rules with missing base version are available
4. At least one prebuilt rule with missing base version has update available

Steps to reproduce:

Scenario 1:

1. Customize a field covered by the scalar diff array (e.g., tags, references).
2. Upgrade the rule using the Rule Updates table or Upgrade Flyout.
3. Confirm that is_customized=true after the upgrade (expected behavior).
4. Revert the modifications via the rule customization options.

Scenario 2:

1. Customize a field covered by the scalar diff array (e.g., tags, references).
2. Revert the modifications via the rule customization options.
3. Confirm that is_customized=true after the changes are reverted (expected behavior).
4. Upgrade the rule using the Rule Updates table or Upgrade Flyout.

Current behavior:

After reverting changes and updating the rule (or updating the rule then reverting changes), the rule remains marked as customized (is_customized=true) even though no actual modifications exist and we've stored the most recent version.

Expected behavior:

If a rule customization is reverted, the rule should no longer be marked as customized, and is_customized should be set to false.
Once the rule is updated, it will have a base version again, as we always store the most recent version of a rule in the package. This means that after the update, the rule should behave like any other rule with a base version and should follow the standard logic where reverting the customization resets is_customized=false.