Add support for reverse ordering in link queries (Issue #1) #1

- Add "reverse" boolean parameter to three endpoints:
1. getManyToManyCounts (grouped counts)
2. getBacklinks (links to subject)
3. links (target links)

- Implement reverse iteration logic in both storage backends (mem_store
and rocks_store) for __reverse-chronological__ ordering

- Update HTML templates with (reverse) checkboxes

- Add "reverse" boolean parameter to three endpoints:
1. getManyToManyCounts (grouped counts)
2. getBacklinks (links to subject)
3. links (target links)

- Implement reverse iteration logic in both storage backends (mem_store
and rocks_store) for __reverse-chronological__ ordering

- Update HTML templates with (reverse) checkboxes

Before all our testing was done manually. This fixes the remaining failing automatic tests.

Adds test coverage for the reverse parameter in get_links and
get_many_to_many_counts methods. Tests verify that reverse: true
returns results in oldest-first/descending order while reverse:
false returns newest-first/ascending order.

The initial implementation of the reverse ordering feature had a flaw
in how it handled pagination. When `reverse=true` was set, the code
would reverse the entire collection before applying pagination
slicing, which broke the cursor logic. Cursor positions were
calculated relative to the original ordering but applied to a reversed
set of items, causing duplicate results or skipped items across page
boundaries.

The fix restructures pagination to account for reverse ordering:

- In reverse mode, pagination starts from the beginning (oldest items)
and moves forward, with begin/end indices calculated accordingly
- In normal mode, pagination continues working backward from the end
(newest items) as before
- The result slice is reversed __only after__ pagination boundaries
are established, ensuring cursor values remain consistent

Applied to both storage backends (mem_store and rocks_store) for
consistent behavior across implementations.