Sync repeatedly crashes with NSRangeException (out-of-bounds array access) on macOS, pins CPU indefinitely

Update - identified the offending file and root cause.

Offending file: a scanned film JPEG (from a mail-order film lab scanner, EXIF CreatorTool "EZ Controller"), confirmed stuck via the Sync Activity panel showing "Uploading... Metadata" indefinitely on this asset.

Root cause: the file's XMP had a custom Point Tone Curve. The master (RGB composite) curve (crs:ToneCurvePV2012) had exactly 3 points, and the Green channel curve (crs:ToneCurvePV2012Green) also had exactly 3 points. Red and Blue channels had 2 points each (near-default linear).

The crash's array bound - "index 18446744073709551615 beyond bounds [0 .. 2]" - is NSNotFound (-1) cast to an unsigned 64-bit index, passed into objectAtIndex: on a 3-element array. This lines up with a 3-point curve.

Isolation: I added a 4th point to the Green channel curve only, leaving the master curve at 3 points. Restarted Lightroom Classic. Sync completed cleanly (Local Activity now shows "Synced," CPU back to baseline, zero NSRangeException entries in the console log this session vs. one within ~90 min on every prior session).

This isolates the trigger to the per-channel (R/G/B) curve array specifically, not the master/composite curve - the master curve kept 3 points throughout and did not reproduce the crash once the Green channel was changed. My working theory: Lightroom's cloud sync remaps Develop-module point curves into the fixed anchor model used by Lightroom mobile's curve UI. That remap appears to run per-channel, and when it does a named-anchor lookup against a channel curve with a non-standard point count (3, in this case), it gets -1 (NSNotFound) back and passes it straight into objectAtIndex: without a bounds/NotFound check. The master curve going through the same path without crashing suggests the master and per-channel (Red/Green/Blue) curves are handled by different code paths in the serializer, and the bug is specific to the per-channel path.

Suggested fix for Adobe engineering: add a NSNotFound guard before indexing in the per-channel curve remap step of the sync serializer, and/or support arbitrary point counts in the cloud curve model for R/G/B channels, not just the master curve. Workaround: a custom per-channel (Red/Green/Blue) tone curve with exactly 3 points appears to trigger this; adding or removing a point on that channel avoids it. A 3-point master curve alone does not trigger it.