[CmdPal Calculator] Fix issue for multi-argument functions where comma is both the number group separator and list separator

[daverayment]

Summary of the Pull Request

This fixes Calculator functions with multiple arguments in cultures where the number group separator and list separator are identical, e.g. en-US and en-GB.

It maintains existing parsing behaviour for other cultures where the separators differ, e.g. de-DE.

PR Checklist

• Closes: [CmdPal Calculator] Functions with multiple arguments are broken for cultures with comma as both group and list separator #47726

• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

The root issue was in the number translation step. In cultures such as en-US, commas were being consumed as part of numeric tokens and were treated as number group separators, which broke functions whcih took multiple arguments. For example, max(1,2) would be translated as max(12) and pow(2,3) as pow(23). The number translator's result would be passed on to ExprTK, which could sometimes still interpret the input and would give a result (12 in the case of max(1,2)); for cases like pow(2,3), it would surface an error, as the expression pow(23) is invalid.

This fix resolves the ambiguity in two ways:

• It uses stricter grouped number matching when the culture's list separator and number group separator are the same.
• It preserves separator characters for multi-argument functions. This means that expressions like max(123,456) are correctly interpreted as two arguments inside the function call, while 123,456 outside a function call is still interpreted as a grouped number.

Care has been taken to preserve grouped numbers inside single-argument functions, e.g. ceil(123,456.23).

The more permissive parsing for cultures which do not have this ambiguity has been retained. (Arguably this is too loose, but that's something to consider separately.)

Validation Steps Performed

Added and updated unit tests, with en-US used as the representative 'ambiguous culture'. Coverage includes:

• max(), min() and pow()
• Grouped numbers in single-argument functions like ceil(), floor(), round(), log() and sin().
• Nested expressions
• Spacing around function calls
• Scientific notation
• Hexadecimal, binary and octal literals

All tests pass:

Manual testing was also performed to confirm:

• Multi-argument functions now evaluate correctly

• Grouped numbers inside single-argument functions still work

• Nested expressions and spacing variations are handled correctly