duplicate results in rmc preload can result in missing blob

since maps are stored in preload by trackid, and we dont fail if the blob already exists, you can get two messages in queue for the same map in download. thus the first search+download will delete the map from blob, and the second search+download will not find a blob. if tmx api is down in this scenario, then we'd be in an invalid state.

potentially could tie blobs to queue messages by like a message id or something to force the 1-1 relationship between the two. or minimally fail to preload the map at all if the blob already exists.

having a more enforced 1-1 relationship will ultimately be better for the rmc preload, but we lose flexibility in this api for other usecases. as basically you wont be able to download a map from the cache unless it came from a queue message