Cloud Manager: a new file's upload finishes its steps even when Ekahau answers late

Suite 2.235.7, Cloud Manager 4.90.5. Every other tool is unchanged.

What changed

Filing the upload into its site is asked again if Ekahau refuses it. Right after an upload, Ekahau lists the new project before the site service can see it, so the first request to file it into a site could be refused and the project was left under Unassigned projects. The request is now repeated for up to about eleven seconds before the refusal is reported.
Syncing the cloud copy back is asked again the same way. The download that writes Ekahau's project id into the local file is repeated if the first attempt is refused, instead of leaving the local file without the id. If it still fails, the message carries Ekahau's reason and the local file is left untouched.
The row is settled after the first upload. The sync back now records that the local file and the cloud project match, as the replace action already did. Previously a first upload finished without that record, and the row could show a change on one side.
A failed rename is reported. When the cloud project cannot be renamed to the file name, the result now says so, and the failure is written to the log (About, Diagnostics). The site assignment and the sync back still run.

A site assignment refused twice, and a download refused twice, both complete on the third attempt. A step that keeps failing is still reported with its reason, and a failed download leaves the local file byte-for-byte as it was.
The sync point is recorded under the new project id after a successful sync back, and not recorded when the sync back failed.
Four of the eight new tests fail with the previous code restored.