Potential race condition with GitHub actions

I think there is a potential race condition with the "'publish-pages" job I added to GitHub actions in #184.

The danger occurs when there are multiple pushes (i.e. merged PRs) to the "main" branch in close succession. I added `concurrency` to the publishing job to prevent overlapping deployments to the web site. I think this makes sense because overlapping deployments could interfere with one another, causing corruption to the deployed web content.

However, there is no guarantee that the latest push will be published. Consider the following scenario when two PRs are merged in close succession:

* PR 1 is merged first, GitHub actions starts running
* PR 2 is merged next, GitHub actions starts running
* PR 2 happens to reach the "publish-pages" job first, and deploys
* PR 1 waits for PR 2 to complete, and then it executes "publish-pages"

As a result, changes from PR 2 are not published to the web site.

It seems like this could be fixed by adding an `if` condition to the "publish-pages" job which skips the job unless the SHA of the "push" event that triggers the workflow is currently the head of the "main" branch.

I'm not much of an expert in GitHub actions. @oddhack or @outofcontrol do you happen to know this stuff better? Is the solution I suggest the right way to fix this?

Find the GitHub Actions workflow containing the "publish-pages" job and review its concurrency settings and the push event SHA. Verify that publishing is skipped when the triggering SHA is no longer the head of main, then test the behavior with closely successive pushes or workflow runs.

Written by the indexing model from the issue text.