When checking for updates, we were polling every 10 seconds. Aside from

CI builds, most results are returned much faster than that, and often

would result in an e-mail going out with the review before the page even

got its update.
This change reduces the time from 10 seconds to 2, which is going to be

a better experience in most cases.
The polling interval has exponential backoff applied, with a multiplier

of 1.15, and a cap of 10 seconds. For very long-running checks, like CI

builds, this will be more reasonable, and will avoid swamping the server

indefinitely.
To do this, a bug/unutilized feature in the backend was addressed. We

had a mechanism for filtering updates by timestamp, and this wasn't

being used by the frontend at all. A recent change introduced a

timestamp that could be used by the backend, with filtering done on the

frontend.
The server-side filtering would have been ideal, but was broken due to

trying to compare timestamps with microseconds to timestamps without.

That has now been fixed, with issue summary table timestamp comparisons

being added to the backend. This allows us to remove the front-end

tracking of per-entry timestamps, add a max "last timestamp" variable,

and use that to rely on the ?since= parameter.

Tested with extensive log output and checking both the client-side

and server-side output. Verified that the polls started at 2 seconds

and then backed off over time.
Tested that the timestamp calculations server-side with ?since=

is now working correctly.
Tested that empty payloads were no longer causing crashes (which only

now happens because timestamp calculations are fixed).
Tested that no updates came in without making changes to the timestamp

server-side.
Python and JavaScript unit tests pass.