Inconsistent state when cropping a hi-res image failed because of timeout

## Short description
When receiving status 500 (presumably because of timeout) during cropping a hi-res image, the metadata of the image in S3 and ES (Elasticsearch) can end up in an inconsistent state. This inconsistency leads to:

- Failure to download the cropped image even if its thumbnail appear on the left side panel of cropped images (happens if there is inconsistency between S3 and ES).
- Failure to display the cropped images as thumbnails on the left side panel (happens if there is inconsistency within S3)

## Steps to reproduce
This can be quite tricky to reproduce. Cropping a hi resolution image often lead to status code 502, in which case no inconsistency in S3 and ES is observed. Perhaps we can simulate a network partition by intentionally throwing an unhandled exception somewhere during the call to `POST /crop`

## Actual results

Assets did not have the expected widths for 1000.jpg and 10379.jpg (there are only 3 out of 5 in assets)

Exports did not have crop id 266_0_10379_5843

## Expected results

There should be 5 out of 5 images in assets

As there were 2 items in cropper data, there should also be 2 items in image exports

## OS and browser details
MacOS Monterey 12.4, Chrome 103

Start by tracing the POST /crop flow and how it updates image metadata in S3 and Elasticsearch, then examine where a timeout or unhandled exception can interrupt those updates. Reproduce the failure with an intentionally raised exception or equivalent simulated network partition, and consider the issue done when the expected asset and export records remain consistent after a failed crop.

Written by the indexing model from the issue text.