fix(progress): omit epubcfi for paging documents (cbz/pdf/djvu)

collectBookData put getLastProgress() directly into the epubcfi field
for every document. For paging documents (has_pages == true: PDF, CBZ,
CBR, CB7, CBT, DjVu) that value is the current page as a *number*, so
the payload carried "epubcfi": 5 (a JSON number). The server types
KOReaderBookProgress.Epubcfi as *string, and the strict JSON binder
rejected it with a 400 ("cannot unmarshal number into ... epububcfi of
type string"), which the plugin surfaced as the misleading
"Failed to push progress. Check your network connection." Reflowable
EPUBs were unaffected because CREngine returns an xpointer string.

Only set epubcfi for rolling (reflowable) documents. Paging documents
carry their position in the numeric page/total_pages fields, which the
server already treats as the canonical locator for fixed-layout/comic
formats. The pull path already falls back to progress.page, so restore
keeps working.

main.lua

@@ -785,7 +785,6 @@ function Bookhoard:collectBookData()
         title = title,
         authors = authors,
         percentage = percentage,
-        epubcfi = progress,
         context_text = context_text,
         page = page,
         total_pages = total_pages,
@@ -796,6 +795,15 @@ function Bookhoard:collectBookData()
         },
     }
 
+    -- epubcfi (a CREngine xpointer) is only meaningful for reflowable (rolling)
+    -- documents. Paging docs (PDF/comics/DjVu) carry their position in
+    -- page/total_pages; a bare page number here would be a JSON number into a
+    -- server *string field and fail the bind. Reflowable EPUBs are always
+    -- rolling, so they keep sending the xpointer exactly as before.
+    if not self.ui.document.info.has_pages then
+        book_data.epubcfi = progress
+    end
+
     return book_data
 end