Profile Status column can show a fork PR's CI result, because the branch=main run filter also matches PRs whose head branch is named main #211

What's wrong

GitHubApiClient.GetLatestWorkflowRunAsync (KtsuBuild/Profile/GitHubApiClient.cs:176-195) requests /repos/{org}/{repo}/actions/workflows/ci.yml/runs?per_page=1&branch={defaultBranch} and takes runs[0].

The Actions branch filter matches a run's head_branch. For a pull_request run, that is the PR's head branch. A contributor who forks a repository and opens a PR from their fork's main produces a ci.yml run with head_branch: main. Consumer ci.yml workflows run on pull requests as well as on push and schedule.

Failure scenario

An external contributor opens a PR from someone/Semantics:main and its build fails. If that is the newest ci.yml run when the daily profile job runs, the org README shows Semantics as failing while main is green. A passing fork PR can hide a real red main in the same way. The badge stays wrong until the next regeneration.

Suggested fix

Ignore PR-triggered runs: add event=push to the query, or fetch a few runs and take the first whose event is push, schedule or workflow_dispatch. #161 changes this same endpoint (it adds status=completed for the in-progress "unknown" case), so one PR could fix both.

Acceptance criteria

• The Status column only uses runs triggered by push, schedule or workflow_dispatch on the default branch.
• A GitHubApiClientTests case with a fake response whose newest run is a pull_request event with head_branch: main shows that run is ignored.