Browse: keep a proven last page when the record count arrives or shrinks, not only when it's unchanged #1963

What happens

After #1958, Browse remembers that a page is the last one only while the table's record count is the same as when that was proven. A count that moves lets Next probe past it again, which is what fixes #1940.

The rule is strict equality, so a remembered last page is also dropped when nothing new could be past it:

• The count first arrives. The proof was made before the count was known, and the count then loads.
• The count shrinks. Records were deleted, so a page that was last is still last, or now past the end.

Either way the next step costs one extra probe of the page after it. That probe comes back empty and proves the last page again. Nothing is shown wrongly and Next still works, so it's one wasted read, not a bug the user sees.

Possible improvement

Only retire the proof when the count grows: keep it when the count first arrives, or when it shrinks. It's a small change to the proof check in DatabaseTableView.tsx, and needs a test for each of the three cases.

Low priority: the cost is one read per step after a deletion or an initial count load.

Review-Deferral: a3b75b0e1d3e87f1 severity=nit category=correctness

Raised by the cross-model review of #1958 (#1940).

_{🤖 Generated by Anthropic Claude Code (Claude Opus 5.5); posted via @dawsontoth.}