fix(Scroll to Bottom): Feature corrupting visible queue contents

[marcustyphoon]

Description

This fixes an issue where using Scroll to Bottom on the queue page made a bunch of clones of my queued posts appear. This is, obviously, pretty bad. I didn't test what happens if you e.g. delete one, thinking you have it queued twice, but yeah. My guess is this is caused by sortablejs (as I only observe it on queue), likely a race condition when the load-more-posts code gets called at an unexpected time.

Quick test: Object.groupBy([...document.querySelectorAll('[data-id]')].map(element => element.dataset.id), id => id)

Putting our programmatic scroll in an rAF seems to fix this. Fortunately, two doesn't seem to be needed; that would result in an extra render occurring each time we scroll, which would be slower (likely making #1793 worse). One, I would guess, just shifts the scroll and resulting observer callbacks to later in the same synchronous event loop iteration, potentially changing the amount of js code that's run but not really affecting the render loop.

I was going to make this predicated on ${keyToCss('timeline')} > .sortableContainer, but it doesn't seem to really slow down or have ill effects on the feature in general, so perhaps better safe than sorry?

Testing steps

• Confirm that Scroll to Bottom functions normally on a normal timeline and on following/followers and stops when reaching the end of a timeline. (I should probably list more here. I dunno, I couldn't think of a specific thing to test.)
• Scroll to the bottom of a queue page with multiple pages and use the above snippet to confirm that each post only appears once.
• If desired, unrevert the test commits, open tabs with this code and with the original code substituted, scroll to the bottom of a moderate-length timeline, and confirm that about the same amount of time elapses.

I think this one's honestly more of a "can you think of an error-state-causing race condition that could occur with this based on looking at it." I think I can't?