Editor hangs and reports assets as corrupted when the Unity DataStore service process terminates

Steps to reproduce:

1. Create a new 3D URP Project
2. Wait for all background processes to finish
3. In the Task Manager, end the Unity.DataStore.exe process
4. Interact with the Editor for 10 seconds

Actual results: Every artifact read blocks for 60 seconds waiting on the dead service and then fails with "Error loading the file 'VirtualArtifacts/Primary/<hash>'. File is either empty or corrupted, please verify the file contents" - with a different artifact hash on each occurrence. The Editor gets stuck on a "Hold on (busy)" progress dialog (in this session on EditorApplication.delayCall: ReadmeEditor.SelectReadmeAutomatically, "Waiting for user code in Assembly-CSharp-Editor.dll to finish executing") and never recovers. The DataStore service is not restarted and no error about the lost service is shown. The Editor has to be terminated manually via the force quit button.

Expected results: The Editor detects that the DataStore service is gone and either restarts it and recovers, or fails with a clear error identifying the problem; artifact reads are not misreported as file corruption

Reproducible with versions: 6000.6.0b8, 6000.7.0a5

Can’t test with versions: 6000.0.82f1, 6000.3.22f1, 6000.5.9f1

Tested on (OS): Windows 11

Notes:

• Editor-UDS.log shows the mechanism: "[Error] Wait handle timed out after 60000" with the stack uds_internal_wait_handle_complete -> uds_access_content -> UDSFileSystem::Read -> ArtifactFileSystem::Read -> File::Read, repeating per read
• The reported "corrupted" artifact hash differs on every occurrence, so this is a wholesale failure of artifact store access, not a problem with any specific asset
• [Internal link] reports the same "Error loading file from VirtualArtifacts" signature with an Editor hang occurring spontaneously during a content build without anyone terminating the service, which suggests this failure path is reachable in normal use and not only via manual process termination
• The service process can terminate in real use for many reasons (crash, out-of-memory kill, antivirus, machine pressure), so the Editor's failure handling for a lost DataStore service matters beyond this synthetic trigger