lvdocview: fix source page numbers with a page-list not in reading order

[albertmichaelj]

Fixes #688.

Problem

The page map is built in page list order, and LVDocView::updatePageMapInfo() made _page/_doc_y non-decreasing in that list order. But a page list is not required to be in reading order: conversions commonly move front matter (a copyright page) to the end of the spine while the page list keeps referencing it among the front matter, which is what the DAISY page-list guidance asks for, and epubcheck dropped its reading order requirement in w3c/epubcheck@d0f12a9.

With such a page list, one out-of-order entry raises the clamping values to a near-the-end position, and every entry after it is clamped up to that. With the two sample EPUBs from #688 (identical spine title(i) ch1(1) ch2(2) ch3(3) copyright(ii), one with the page list in print order i, ii, 1, 2, 3):

rendered page	0	1	2	3	4
before	i	i	i	i	ii
after	i	1	2	3	ii

So the source page number freezes on the last label before the out-of-order entry, and the page numbers in the margin all pile up at that one position.

Fix

updatePageMapInfo() now resolves each item's position with no clamping, orders the items by that resolved position, and only then ensures page numbers don't go backward. Three commits:

1. lvtinydom: add LVPageMap::sortByDocY() — private helper (LVDocView made a friend, as it already is of LVPageMapItem): insertion sort on _doc_y, tie-broken on _index.
2. lvdocview: updatePageMapInfo(): order page map by resolved position — the fix itself.
3. lvtinydom: LVPageMap::sortByDocY(): keep _index in sync — the extra pass you asked for, kept separate so it is easy to review or drop.

Notes for review

• The implementation is @tachibana-shin's, from crenginex@5dd88b3 + its std::sort → insertion sort follow-up, used with their permission and credited via Co-authored-by:. Two changes to it: the _index pass above, and the handling of unresolvable entries below.
• Sorting is skipped when the resolved positions are already ascending, so nothing changes for a page list in reading order, nor for synthetic page maps (buildSyntheticPageMap() walks the document in order).
• Items whose XPointer doesn't resolve are given their list predecessor's position in pass 1, so they stay next to it and inherit its page number, as before. (Leaving them at _doc_y = -1 and filling them in after the sort would instead move them all to the start of the page map.)
• The page map ends up in reading order, which is what consumers already expect: cre.cpp binary searches it by doc_y to find the current or a visible page label ("We expect items to be ordered by doc_y"), and reads the first and last items as the first and last page labels. The "go to page" list follows reading order too, so jumping to a page lands where the label is.
• The page map is serialized in _children order, so a book already in cache keeps its old page map until its next re-render (any setting change triggering one, since render() calls invalidatePageInfo()). I did not bump CACHE_FILE_FORMAT_VERSION for this — your call if you'd rather have it fixed on first reopen.

Testing

• Both translation units compile with no new diagnostics.
• The two functions were also copied verbatim into a standalone harness with stubs, checking: the sample EPUB above (labels advance i 1 2 3 ii), a reading-order page list left untouched with no sort, stability and _index renumbering on entries sharing a position, unresolvable entries, an entry past the last rendered page, empty/single-item page maps, idempotency on a second run, and 2000 randomized page maps (ordered, stable, _index = 0..n-1, positions preserved).
• Not yet exercised in KOReader itself — I'd need to build koreader-base against this branch; happy to do that if you want it before merging.

---

This change is 

[poire-z]

Thanks. Reads well.
@tachibana-shin : any comment ?

[tachibana-shin]

I think it's good