Unable to figure operation of my github status check operation

This is my protected branch (master) configuration:

And this is what I tried:

$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 306 bytes | 306.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: Required status check "build-pipeline" is expected.
To github.com:AdityaGovardhan/my-repo.git
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'git@github.com:AdityaGovardhan/my-repo.git'

So I have a github my-repo repository. I have a build-pipeline GitHub Action which I have kept as required for a commit to be added to master. Here's what the required checks statement says:

Choose which status checks must pass before branches can be merged into a branch that matches this rule. When enabled, commits must first be pushed to another branch, then merged or pushed directly to a branch that matches this rule after status checks have passed.

So here's what I expected would happen. I can push from my local master to remote master (which is protected) directly because of that last statement^, but the commit will be in an intermediate state at remote because build-pipeline status check have not been successful yet. I am aware that that's not how git works. But then what's the point of that last statement^ when it is forcing me to create a non-protected branch and raise a pull request to perform build-pipeline status check and then merge to master.

On GitHub, status checks are applied to a commit. While the typical workflow is to open a PR and merge changes that way, it may be possible to push your changes to a different branch, let the status checks run there, and then fast-forward your master branch to that version. The commit would already have passed the checks.

Note that I have not tested this, and again, it's not the usual workflow, it may be something you can try. It would be a potential workflow option for people who do rebases and prefer a linear history.