Channel revision tracking is overwritten when opening new tabs

[bjester]

Observed behavior

After a user has opened a Studio channel, the revisions tracking which is used to identify the current state in the channel's change history, gets overwritten. This means that for channels with a large number of historical changes, the requests to the sync endpoint will attempt to return all historical changes.

Expected behavior

The frontend should not overwritten the session tracking for channel revisions and the sync API should not freely attempt to return changes from all-time for a channel.

User-facing consequences

Inconsistent state between the server and client and many possible side effects because of the inaccurate revision tracking.

Additional information

We observed OOM kills of gunicorn because of the sync API attempting to buffer large responses because of the large discrepancy between the requested server rev and the current revision of the channel.

Steps to reproduce the issue

1. Open a channel, which has had some real modifications performed
2. Open the Network inspector in DevTools for the channel page
3. Open Studio in another tab
4. Observe in the DevTools the request to the sync endpoint starts out with a non-zero revision for the channel, then once another page is opened, sends a 0 revision integer

[rtibbles]

Fixed in #4897