Support querying scratches by last_updated

[ribbanya]

#952 addressed a performance issue with paginating scratches by last_updated. However, it would still be quite useful to be able to query the API by a last_updated timestamp, and get back all the scratches that were updated since that time. The difference between paginating by creation_time and querying by last_updated is subtle, but I believe it is important in a couple ways.

If someone wants to go very far back, potentially requesting all scratches that have ever been created, it makes sense to paginate them by creation time so that the order never changes and the index is never rebuilt. cursor tokens returned by the API can be reliably stored and reused by any number of users, without incurring additional indexing cost to the backend.

However, if a user is only interested in recent changes, last_updated is a much more useful filter parameter. The intention of this query is for the result set to be quite small, and restrictions could be accordingly placed on the response, such as limiting to the most recent 100 (or some other small number) or so records. Meaning, when filtering by last_updated, you are not allowed to see past the most recent 100 scratches from now, and if you want to go back further you must use the cursors provided by creation_time.

This functionality would also allow the front page to revert to its behavior prior to #952 of showing the most recently updated scratches.

Related to #307.