Fix cursor pagination crash on empty page

[joshhanley]

The Scenario

When a Flux pagination component renders cursor pagination on an empty page, Flux can throw an error instead of rendering the pagination controls.

This can happen when a stale cursor URL is opened, records are deleted, or filtering leaves the current cursor page empty.

<flux:pagination :paginator="$users" />

The Problem

Flux's simple pagination view calls ->encode() directly on the previous and next cursor values:

$paginator->previousCursor()->encode()
$paginator->nextCursor()->encode()

Laravel's cursor paginator returns null from previousCursor() and nextCursor() when the current page has no items. The pagination buttons can still render in that state because they are controlled by onFirstPage() and hasMorePages().

That means Flux can call encode() on null while rendering the previous or next button.

The Solution

Use the same approach that was merged in Livewire in livewire/livewire#10302.

Capture the previous and next cursors before rendering the buttons, then fall back to the current cursor when Laravel returns null.

The wire:key and setPage calls now use null-safe encoding, so an empty cursor page reloads the current cursor instead of throwing while the view renders.

Related to livewire/livewire#10302

[calebporzio]

Reproduced the crash and verified the fix end-to-end in a fresh Laravel app with Flux as a path repo:

1. Seeded 12 users, grabbed the nextCursor() from page 1, deleted all rows, then requested the page with that stale cursor.
2. On main: 500 — Call to a member function encode() on null (from both the previous and next button paths).
3. On this branch: renders fine — the empty page shows the pagination frame and the button falls back to the current cursor, so clicking it just reloads the same page. That matches what Laravel's own views do (previousPageUrl() returns null and the anchor reloads the current URL), and matches the approach already merged in livewire/livewire#10302.

Also sanity-checked non-empty pages: page 2 of a seeded set still emits the correct distinct prev/next cursors, so normal pagination behavior is unchanged.

Thanks Josh!