Change scratch view pagination ordering to creation_time

[ribbanya]

Recently, the site experienced massive slowdown, at around 11 AM UTC on February 5th, 2024. I believe that my usage of the API is what caused this.

I was using the /api/scratch endpoint to go very far back, filtering by SSBM scratches (preset=63). The last request I sent before the site stopped responding was:

https://decomp.me/api/scratch?cursor=cD0yMDIyLTA1LTA5KzA2JTNBMjclM0EyOC42NDYxMzYlMkIwMCUzQTAw&format=json&page_size=100&preset=63

This PR changes the ordering of the scratch view, as I believe that having a non-fixed ordering is forcing the site to re-index upon requesting records which have been updated since the last indexing. According to the documentation:

Proper usage of cursor pagination should have an ordering field that satisfies the following:

• Should be an unchanging value, such as a timestamp, slug, or other field that is only set once, on creation.
• Should be unique, or nearly unique. Millisecond precision timestamps are a good example. This implementation of cursor pagination uses a smart "position plus offset" style that allows it to properly support not-strictly-unique values as the ordering.
  [...]
• The field should have a database index.

Additionally, @ethteck has noted in our conversation that "it's a bit more complicated, because we want the main page to still order by updates I think." But I don't have the experience to implement that, so I leave it up to you.

[ethteck]

I take back what I said. This looks good to me!

[bates64]

LGTM. I don't think the activity thing is a problem. Thanks for the detailed explanation