fix(tables): re-check the find match at the reveal, not just before paging - #6750

Summary

Follow-up to #6733, which merged while the last review round was still in flight — this is the one fix from that round that didn't make it in.

#6733 added a guard in goToMatch so a match removed while its row was paging isn't revealed. Greptile's next round pointed out one more window: between goToMatch queueing the reveal and the reveal effect running is another commit, and a refetch there can remove the match after the guard has already passed.

• Extracts the membership check into isStillAMatch(match) and applies it at the reveal too — the one place the selection actually moves.
• When the match is gone, the pending jump is dropped and the cursor is released (activeMatchRef nulled, cursorIsOnMatchRef false), so the next step lands on the clamped replacement instead of skipping it.

Without this, a row write or SSE update landing in that window selects a cell that no longer matches and marks the cursor as sitting on a result.

Type of Change

• Bug fix

Testing

• Typecheck, bun run lint:check, bun run check:audits (27 audits), 1313 table tests — all pass on top of current staging.
• The async race itself isn't unit-covered: the existing tests exercise the find bar, and driving this needs the 4,600-line grid mounted with a mid-flight refetch. The invariant is now enforced at both seams that can observe it (post-await in goToMatch, and the reveal effect).

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)