fix: make answers past the first 999 reachable

[culfin]

Two sides of the same limit, which is why they arrive together.

In the browser. The question detail page asked for page_size: 999 and
never asked again. A question with more answers than that simply ended: the
rest exist in the database and cannot be reached from the page. It now requests
page by page, like every other list in the interface.

On the server. The template controller renders the same 999 into the page
it hands to search engines — a page of several megabytes for such a question,
rebuilt on every crawl. Capped at 100, the size the list itself uses.

How it was found, and how common it is

On a forum with 26 years of archive, where one thread has 13,368 answers.

I want to be straight about the scope: this is not visible on a young instance,
and I could not reproduce it on meta.answer.dev because no thread there is
long enough. The limit is hard-coded, though, so any instance that runs long
enough to pass 999 answers on a single question hits it — and when it does, the
answers are unreachable rather than slow.

Replaces #1573 and #1574, which are the same two changes as separate pull
requests.

🤖 Generated with Claude Code

[robinv8]

Thanks for putting the UI and SSR sides together, and for writing up the 13k-answer case so clearly. Making answers past the first 999 reachable is the right fix.

One thing this change will surface: permalinks of the form /questions/:qid/:aid (notifications, shares, comments). After this lands, requestAnswers only loads 15 answers. If the target aid is not on page 1, it never enters res.list, so the page has nothing to scroll to. With page_size: 999 that mostly stayed hidden; at 15 it shows up from answer 16 onward.

A small follow-up in this PR would be enough: when aid is set and missing from res.list, fetch that answer (e.g. GET /answer/api/v1/answer/info?id=) and insert it into the list so the link still lands.

A few smaller notes, none of them blocking:

• requestAnswers can race if the user clicks pages quickly.
• writeAnswerCallback appends the new answer onto the current page, which may not be where it belongs.
• After filtering deleted answers out of list, count can drift from what the pager shows.

Happy to look again once the permalink path works.