rows/rowscanner: set isFinished=true when last page has no more rows

[Dev-X25874]

Problem

In resultPageIterator.HasNext(), when a fetched page has HasMoreRows == false,
the code calls rpf.Close() to close the operation handle on the server but never
sets rpf.isFinished = true.

After Next() consumes that last page and clears nextResultPage, any subsequent
call to HasNext() bypasses the early-exit guard at the top of the function
(which checks isFinished && nextResultPage == nil) and falls through to
getNextPage(). Since isFinished is still false, getNextPage() proceeds to
issue a FetchResults RPC against an already-closed operation handle, resulting
in a spurious server-side error instead of a clean io.EOF.

Fix

Set rpf.isFinished = true alongside rpf.Close() in the no-more-rows branch,
mirroring what the error path in the same function already does correctly:

// before
if !nrp.GetHasMoreRows() {
    rpf.Close()
}

// after
if !nrp.GetHasMoreRows() {
    rpf.isFinished = true
    rpf.Close()
}

Impact

Any caller that invokes HasNext() more than once after the last page is consumed
— a reasonable and common pattern — would previously receive an unexpected RPC
error. After this fix they receive false / io.EOF as intended.

[vikrantpuppala]

This change is functionally a no-op — rpf.isFinished is already true by the time we reach line 137.

Tracing HasNext → getNextPage: the fetch loop at line 177 always runs at least once (the loop entry condition !Contains(Start()+Count()) is always true because Contains uses an inclusive [start, end] range and Start()+Count() == end+1), and lines 202–205 unconditionally write rpf.isFinished from HasMoreRows. So when control returns to HasNext and we enter the !nrp.GetHasMoreRows() branch, isFinished is already true.

The early-exit guard at line 117 (if rpf.isFinished && rpf.nextResultPage == nil) therefore already short-circuits any subsequent HasNext() after the final page is consumed — no spurious FetchResults RPC, no server error. I can't construct a path on main where the described bug actually fires; do you have a concrete repro (stack trace, server log showing FetchResults after CloseOperation, or a failing test)?

[Dev-X25874]

You're right, and I appreciate the careful trace. I missed that getNextPage()'s fetch loop always executes at least once — Contains(Start() + Count()) resolves to start + count <= start + count - 1, which is always false — so lines 201–205 unconditionally write isFinished from HasMoreRows before returning. By the time HasNext() reaches the !nrp.GetHasMoreRows() branch, isFinished is already true, and the guard at line 117 correctly handles all subsequent calls.
I don't have a concrete repro because the code path I described doesn't actually exist. I'll close this PR. Thanks for taking the time to walk through it.