Narrow field values with truncatingIfNeeded instead of the trapping initializer

[JanLahmann]

What

rzfit_swift_string_for_type narrows a FIT_UINT32 into the field's own type (FIT_ENUM, FIT_UINT8, FIT_UINT16, …) with the exact initializer:

case 1: return rzfit_swift_string_from_file( FIT_ENUM(val) )

FIT_ENUM(val) traps when val does not fit a byte. A structurally valid FIT can carry such a value — a vendor's private enum, or one corrupt byte in an otherwise good file — and then FitFile.init takes the whole process down before the caller sees a line of it. There is nothing to catch: it is a Swift runtime trap, not an error.

This PR changes the one line in the generator (python/fitsdkparser.py, swift_stmt_case_type_function_call) and the generated rzfit_swift_map.swift it produces to truncatingIfNeeded:, which is what the C SDK does when it reads the same bytes into the narrower type, and adds a test with a value that does not fit an enum and one that does not fit a uint16. The generated diff is 179 lines, all of the shape FIT_X(val) → FIT_X(truncatingIfNeeded: val).

How it was found

A mutation fuzz over a corpus of Garmin recordings in a wing-foiling app that imports a rider's whole year from intervals.icu: one tester's first sync crashed the app on their first activity, the crash was inside the decoder, and no amount of validation on our side (header, CRC, message framing) could see it, because the file is valid. We are shipping a vendored copy with this change until it is upstream; thank you for the library.

[roznet]

Thanks a lot for this, and for the very clear write-up — the trap is real and a library should never take the host app down on a bad (or merely unusual) file. Tests pass locally and the generated diff is exactly the mechanical change described.

One refinement I'm going to make as a follow-up on main right after merging: truncatingIfNeeded turns an out-of-range value into a plausible but wrong name. E.g. in the new test, fit_type: 1, val: 0x1_0001 truncates to 1 and returns "device". I'd rather not fabricate a label, so the follow-up switches the generator to FIT_X(exactly: val) and falls back to the existing default "fit_type_\(fit_type)_\(val)" when the value doesn't fit, keeping the raw value visible. The test will assert the exact fallback string.

I'll also fix the same class of trap in FitMessage.swift (FIT_UINT16(val) on a Double for native_field_num).

Merging now — thanks again!