Reading progress (lastPageRead) isn't remapped when tall-image splitting changes a chapter's page indices

Summary

lastPageRead is stored as a plain page index and is only ever clamped against the current pageCount (see ChapterMutation.kt's updateChapter handling, and updateChapterPersistence/refreshChapterPageList in ChapterForDownload.kt). It's never remapped when the meaning of an index changes.

Once the tall-image splitting feature proposed in #2288 lands, downloading a chapter can insert extra page files earlier in the sequence (a single tall page becomes several files). This shifts the index of every page after the split point.

Repro

1. Read part of a not-yet-downloaded chapter up to some page N (client sends updateChapter(lastPageRead: N)).
2. Download that chapter, and have some page before N split into multiple parts during the download (per #2288).
3. Reopen the chapter.

Expected

The reader resumes at the same logical page the user left off at.

Actual

lastPageRead is still N, but N in the new, split-aware file indexing no longer refers to the same logical page - it now points to whatever page ended up at that position after the extra split-generated files were inserted earlier in the sequence. The reader silently resumes at the wrong page.

Note

This isn't specific to reading a chapter live before downloading it - the same shift happens for a chapter downloaded from scratch, as long as a split occurs before whatever page index was already recorded as read (e.g. from a prior partial read, or synced from another device/KOReader). Filed while reviewing #2289's fix and cross-checking its interaction with #2288's proposed splitting; not something the #2289 fix addresses since it's purely about download/read concurrency, not about what page indices mean after a split.