[BUG] greaterOrEquals operator doesn't fail for some invalid strings

[JohnathonMohr]

Describe the bug

If a rule is written using greaterOrEquals comparing against a string such as "1.2", rule loading and evaluation doesn't complain, and comparisons still happen. greaterOrequals may be parsing "1.2" as a date and comparing values against whatever date it ends up being.

Expected behavior

"1.2" likely isn't intended to be a date, but instead is more likely to be mistakenly specified as a "number" to compare against. Until such a feature is supported (i.e. parsing a number from a string to compare against - no guarantee this will ever be implemented) a rule definition with this pattern should fail, since greaterOrEquals (and other related operators) aren't designed to compare strings. (Comparing string-encoded DateTime values is a special case, and "1.2" should NOT be interpreted as that case.)

Reproduction Steps

{
  "resourceType": "Microsoft.Web/sites/config",
  "path": "properties.minTlsVersion",
  "greaterOrEquals": "1.2" // this is invalid for this operator, but the rule executes without errors
}

Environment

No response

[gazzyt]

In my testing (GB locale) the string "1.2" was converted to date 1/2/2025 prior to comparison in method InequalityOperator.GetFinalComparisonTermIfValid