Bypass the threaded EvJobFind for EPUB documents and use WebKit's
WebKitFindController directly. The threaded find job was incompatible
with GepubDoc's single-threaded design and caused segfaults. The new
approach searches within the current page using WebKit's built-in text
search and highlighting, which is both simpler and thread-safe.

Assisted-by: OpenCode:claude-opus-4-6

Store a reference to the GepubDoc in EvWebView via the new
get_doc_handle virtual method. Simplify next_page and previous_page to
just update the document model, letting the page-changed callback handle
content loading. This removes duplicate URI loading and prepares for
reimplementing search with WebKit's find controller.

Assisted-by: OpenCode:claude-opus-4-6

Replace the old approach of modifying extracted HTML files on disk with
a WebKitUserStyleSheet injected via the WebKitUserContentManager. This
is cleaner and works with the new libgepub backend which no longer
extracts files to a temporary directory.

Assisted-by: OpenCode:claude-opus-4-6

Replace the hand-rolled EPUB parsing with libgepub. This removes the
bundled minizip library, custom XML utilities, and temporary directory
extraction in favor of GepubDoc which handles archive access, metadata,
spine navigation, and table of contents. An epub:// URI scheme handler
serves resources directly from the archive without extracting to disk.
Search and night mode are stubbed as no-ops pending follow-up commits.

Assisted-by: OpenCode:claude-opus-4-6

Add libgepub as a required dependency for the EPUB backend in both meson
and autotools build systems. No source code changes yet, but this
prepares for replacing the hand-rolled EPUB parsing with libgepub.

Assisted-by: OpenCode:claude-opus-4-6

In dual pane mode, with a mix of landscape and portrait pages, the wrong
zoom level was getting applied to the wrong panes.

For comic book spreads with the right side page being double-wide, this
was ok. But when the left-page was double-wide, the extra zoom was
applied to the *preceeding* dual pane view (making it extra small) and
the actual wider pane got the standard zoom factor applied.

Add debug logging showing the decision being made, which uncoveres the
bug.

On HiDPI displays, rendered pages use more memory than the cache budget
expects because the size calculation does not account for the device
scale factor. This causes the cache to use up to 4x more memory than
configured on 2x HiDPI displays.

If the current zoom level was within one zoom factor of the limit, it
was not possible to scroll towards the limit. This made smooth scrolling
near the limit awkward, as unless the scroll event had a large delta it
was impossible to reach the zoom limit. Non-smooth scrolling was also
affected, but it was just much more difficult to trigger.

Fix this by allowing zooming while the current zoom level is within one
zoom factor of the limit. Add a new ev_view_can_zoom() function to make
zooming by a factor (as with smooth scrolling) more convenient.

Backported from https://gitlab.gnome.org/GNOME/evince/-/commit/6d299b69

This simplifies the logic required to enable zoom actions for
consumers of the view.

Backported from https://gitlab.gnome.org/GNOME/evince/-/commit/bbfbf913

shell: Add EvFindSidebar widget to show search results
see https://gitlab.gnome.org/GNOME/evince/-/commit/940ce8048e4fc6503dca03c1ce090ff4a11dface

eggfindbar: don't close the findbar when it loses the focus
see https://gitlab.gnome.org/GNOME/evince/-/commit/a2d781fb124bd19861035fd41dacc976e00d19ef

shell: Add the findbar to the main box instead of the view box

libview: Add ev_view_find_set_result