Match.tracepoints is inaccurate when there are submatches

When none of the input coordinates in MatchOptions separates legs, and the Map Matching API isn’t confident about a match between two input coordinates, it terminates one match at the first input coordinate, adds multiple “submatches” to the next input coordinate, and finally adds a match from that input coordinate onward.

This library gained Map Matching API compatibility to support a “Bring Your Own Route” workflow in which the API’s response is converted into Route objects, as if it came from the Directions API. The assumption is that each match spans the entire distance between the first and last input coordinates, but that isn’t necessarily what the API returns. If the API returns submatches, every Match object’s tracepoints property is inaccurate and there’s no way to reconstruct what the tracepoints should be.

https://github.com/mapbox/mapbox-directions-swift/blob/702ed4e8810714db013d59b9c551aa4b85d5e53f/Sources/MapboxDirections/Match/MBMatchOptions.swift#L110-L126

Each match’s array of tracepoints should be filtered down to just the tracepoints whose matchings_index corresponds to the match. It may also help to assert that the waypoint_index increases monotonically.

/cc @mapbox/navigation-ios

Start with Sources/MapboxDirections/Match/MBMatchOptions.swift, especially the linked MatchOptions handling for Map Matching responses. Trace how submatches and tracepoints are assigned, then ensure each Match receives only tracepoints with its matching_index and verify waypoint_index ordering is monotonic.