fix(server): handle stale cache multipart uploads

Resolves https://github.com/tuist/tuist/issues/125564654

Handle stale cache multipart upload completions as an expected conflict instead of an unhandled server exception, and teach the CLI generated client about that response.

S3 can return NoSuchUpload when a client retries completion after the upload was already completed, when the upload was aborted, or when the multipart upload session has otherwise expired. The cache API previously called ExAws.request!/2, so that recoverable storage response raised an ExAws.Error and was reported as an unhandled production error.

This changes multipart completion to use the non-bang ExAws request path, normalizes S3 NoSuchUpload XML into {:error, :multipart_upload_not_found}, and maps that specific cache API case to 409 Conflict with instructions to start a new upload. Other storage errors still propagate instead of being hidden.

The CLI OpenAPI client is regenerated so completeCacheArtifactMultipartUpload has a typed conflict case, and MultipartUploadCompleteCacheService now exposes that server message instead of falling through as unknownError(409). Existing cache storage behavior already treats per-artifact upload failures as non-fatal for the overall store operation, and the new test covers the stale completion case explicitly.

How to test locally

• mix test test/tuist/storage_test.exs test/tuist_web/controllers/api/cache_controller_test.exs
• TUIST_EE=1 tuist generate tuist TuistCacheEE TuistCacheEETests ProjectDescription --no-open
• xcodebuild test -workspace Tuist.xcworkspace -scheme TuistCacheEEUnitTests -only-testing TuistCacheEETests/CacheRemoteStorageTests CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY=""