Rename the CI job to ci so the required status check is satisfied

[Bircck]

.github/workflows/ci.yml already exists here and already builds, tests and packs on every pull request. What it does not do is produce a status check named ci — and that is exactly what the organisation ruleset context-and-oss-required-ci requires on main and release/**.

GitHub names a check run after the job key (or its name:, when one is set) — never after the file name or the workflow name:. This repo therefore emits:

run-ci     ← the job key, from jobs.run-ci

and the ruleset waits for a check called ci that nothing ever produces. On #22 the only check listed is run-ci. Because Team ContextAnd is a bypass actor on that ruleset, our own PRs merge regardless and the missing check shows up as a warning; for an outside contributor it is a hard stop.

The change

Two lines. Workflow name: Check PR → CI, and job key run-ci → ci. Every step is untouched, so the build does exactly what it did before — only the name of the check changes.

After merge the check list on a PR here reads ci, and the ruleset requirement is satisfied instead of pending.

Why the comment above the job

ci is a contract with the ruleset, not a preference. A name: on the job, a strategy.matrix (which renames the check to ci (x)), or an if: that can skip the job on a pull request would each silently break the required check again, so the constraint is written next to the thing it constrains.

Context

None of the 17 repositories in context-and-oss currently emits a check named ci; several also have a default branch that is not main. This is the reference PR for the rest of the rollout — the same two-line shape covers XrmMockup, XrmSync, DataverseQuery, DataverseAnalyzer and DataverseConnection; repos with several parallel jobs (XrmBedrock, DataModelViewer, xrm-emulator) instead keep their jobs and add a fan-in ci job.

The standard is written down in engx: Repository Requirements ("Continuous Integration") and Rulesets.