Block older client code from syncing when we fix sync

[artwyman]

If we fix bugs in sync as proposed in #1271, there's still a problem that tabs running stale code cause conflicts before they are refreshed to pick up new code with the fixes.

We should consider the likelihood of this happening and decide whether it's worth effort to fix right now. Most user actions will involve loading new code (click a link, open a new tab). However there are possible cases which won't (existing open tabs, service worker caching triggered on a slow network).

If we do want to fix it, we can add a version to the protocol URLs in order to prevent older clients from uploading or downloading. We need to block both to be sure of avoiding all of the cases of data getting clobbered, since we don't inherently know if the server or client data is "better".

If we implement this, we should think about how the error appears to the user. Since it's explicitly about old client code, we can't count on adding new client-side detection and modals for it.

We should put some thought into how this might fit into a general protocol versioning scheme in future, which would cover this kind of situation if it happens again. However this specific issue is about a one-off goal not a general system.

[artwyman]

Testing suggests that changing the version in the URL is a workable solution here. E.g. /sync/v2/save -> /sync/v3/save

The client requests will fail, and in the case of an upload may trigger a rapid retry (see #1374), but nothing worse than that, and a reload gets the client out of that state.