Clip rounded profile start to end after clipping rounded end to width / height

[confluence]

Description

This should fix #1395.

I believe that this bug is triggered by the spatially matched images being non-overlapping, which leads to a profile sometimes being requested from the large image with both endpoints being the largest y value (i.e. 999 to 999). When the image is zoomed out and a large mip is used, the endpoints are rounded for decimation (from 999 to 1000). The end is then restricted to the height of the image (999), but we did not consider the possibility that the start value could be equal to the end and thus also need to be adjusted in the same way here.

This PR adds a line to restrict the start so that it does not exceed the end.

In my local test (on Ubuntu), the crash was happening in profile.reserve(end - start);. I'm not 100% sure if @crocka's crash on the Mac (a value being too large to fit in a size_t) was happening in exactly the same place, but it's likely to have had the same root cause (a negative number being incorrectly converted to an unsigned type).

If you cannot reproduce the crash in dev, try reducing the area available for the image viewer component (e.g. by opening the browser console in the window). It's only triggered when the mip is high enough (and I believe when your cursor is in the appropriate area of the image).

If there is no regression, I think this is a low-risk addition.

Checklist

• changelog updated / no changelog update needed
• e2e test passing / corresponding fix added / new e2e test created
• ICD test passing / corresponding fix added / new ICD test created
• protobuf updated to the latest dev commit / no protobuf update needed
• protobuf version bumped / protobuf version not bumped
• added reviewers and assignee
• GitHub Project estimate added

[github-actions]

Package	Line Rate	Health
src.Cache	72%	➖
src.DataStream	44%	➖
src.FileList	67%	➖
src.Frame	36%	❌
src.HttpServer	42%	➖
src.ImageData	28%	❌
src.ImageFitter	83%	✔
src.ImageGenerators	43%	➖
src.ImageStats	75%	✔
src.Logger	37%	❌
src.Main	52%	➖
src.Region	69%	➖
src.Session	4%	❌
src.Table	52%	➖
src.ThreadingManager	67%	➖
src.Timer	85%	✔
src.Util	38%	❌
Summary	46% (8644 / 18966)	➖

[pford]

I tested on a Mac and got almost the same error in the dev branch: libc++abi: terminating due to uncaught exception of type std::length_error: vector. This is fixed in the branch for this PR.

I find it odd that when the second image goes out of view due to spatial matching, the frontend does not update the cursor in the backend with the pixel values outside the image (x < 0, y > max_y), sends two spatial requirements for the matched image as shown below, then does not show the profiles that are sent with the image's last valid cursor (if no stored valid cursor, no profiles). If the spectral profile is set to the active image, spectral requirements are requested and spectral data is sent for the last valid cursor (I assume, not in spectral data message) and shown.

1. Frontend sends spatial requirements {'x': start=0, end=0} {'y': start=999, end=999} with mip=4 (image shape [1231, 999, 301]). Backend resolves the x-range to full range and sends the x-profile for the last valid cursor, but no y-profile. (no error)
2. Frontend sends spatial requirements {'x': start=0, end=0} {'y': start=0, end=0} with mip=1. Backend resolves both to the full range and sends x and y profiles for the last valid cursor.