A README edit no longer publishes a release

This pull request stops documentation changes from shipping a release. Both publish workflows now look at which files a push changed, and they only run when something we actually ship is in that list.

Both publish workflows ran on every push to master. The latest example was a README-only change that moved a badge. It still produced a new PyPI version, a registry publish, a GitHub release, and a fresh Docker image tagged latest. The docs no-bump rule in GitVersion didn't prevent it, because master bumps the patch after every tag.

The fix is a paths filter on the push trigger, the same one in both publish workflows. The package and the image share the source folder and the dependency files. The image also depends on the Dockerfile and its entrypoint. The registry listing is the server.json file. A push that touches none of these, whether docs, tests, examples or CI config, starts neither workflow. The two lists have to stay identical so the image version keeps matching a PyPI release, and both files say so in a comment.

GitHub Actions can't run locally, so the author replayed the rule against real history. For each of the last 15 publish runs, they took the files that push changed and applied the filter. Eleven pushes changed shipped code and would still deploy. Four changed only the README, and those are the ones the filter skips.

The author lists the limits. If the file list ever misses something that should ship, the workflow never starts, so it can't be re-run by hand. The follow-ups they name are a manual dispatch trigger to force a release, or a single changes job that both workflows depend on, so the list lives in one place. Also, edits to the workflows or GitVersion only take effect with the next push that changes shipped code, and the PyPI page refreshes the README only at the next real release. This PR touched only CI config, so merging it was the first push the guard skipped.