[SPARK-57155][INFRA] Fix update_build_status check-run pagination and output parsing

[viirya]

What changes were proposed in this pull request?

Two robustness fixes to the scheduled update_build_status.yml workflow:

1. List a commit's check-runs with github.paginate(..., per_page: 100) instead
   of a single un-paginated github.request, matching notify_test_workflow.yml.
   The default page size is 30, so the target Build check could fall off the
   first page on a SHA that accumulates more check-runs than that (CI matrix,
   external checks, duplicate Build checks from reopened PRs).

2. Wrap JSON.parse(cr.output.text) in try/catch and continue on failure. A
   Build check created by something other than this mechanism (an older
   version, a manual run, or another app), or one with empty output text, would
   otherwise throw inside the loop and abort the whole scheduled run.

Why are the changes needed?

Both issues silently block status updates. If the Build check is paginated off
the first page, the PR stays stuck in queued forever because the updater never
sees it. If an unparseable Build check is encountered, the uncaught exception
aborts the run and blocks updates for every PR queued behind it that cycle.

Does this PR introduce any user-facing change?

No. CI infrastructure only.

How was this patch tested?

Static verification: the embedded actions/github-script body passes
node --check, and the workflow YAML parses. Note github.paginate returns a
flat array, so the iteration was updated from checkRuns.data.check_runs to
checkRuns.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Claude Opus 4.8)

[dongjoon-hyun]

+1, LGTM. Thank you, @viirya .

If possible, could you make this contribution to the sub-projects please?