Guard NumberState format fallbacks

[timbms]

A crash was reported via TestFlight

Summary

• validate and normalize NumberState format strings before calling String(format:)
• fall back to plain number output for unsupported or malformed server patterns
• add regression coverage for indexed and unsupported format patterns

Testing

• xcodebuild test -workspace openHAB.xcworkspace -scheme openHABTestsSwift -destination "platform=iOS Simulator,name=iPhone 17 Pro" -only-testing:openHABTestsSwift/NumberStateTests (builds but did not complete with a usable result in the sandbox)
• swift test --package-path OpenHABCore --filter NumberStateTests (blocked by sandboxed SwiftPM manifest/module-cache permissions)

[TAKeanice]

I like that you are working on properly supporting all format strings from OpenHab. While I think it´s unfortunate that OH just assumes everyone knows that it formats using Java format strings (I did not see much documentation about it, just examples), I can accept it. The Java-printf-style format makes implementation easier for the Android app, too, plus it is simple to understand and locale-aware.

To tackle the Java vs Swift format string incompatibility properly, I once thought we should implement a Java to Swift formatstring conversion. Is this what you did here? If yes, we should publish this as a gist independently - there is nothing like it on the internet yet. If not, what do you think about making this a more comprehensive converter and solve the formatstring problem once and for all?

[timbms]

To tackle the Java vs Swift format string incompatibility properly, I once thought we should implement a Java to Swift formatstring conversion. Is this what you did here?

Of course it would be ideal if there was a Java to Swift formatstring conversion. This is indeed the problem we are facing here. I was thinking not as big as you. But I love challenges.

[timbms]

@TAKeanice Let's first address this crash fix. I will follow up with a wider scope.