This is one of those scenarios where Sandboxes should be considered unreliable relative to Scratch Orgs. When you use Sandboxes, you have to pay attention to the Sandbox Refresh schedule, or you might end up on different versions of Salesforce during the release window.

When you use Scratch Orgs, you can specify which version you want to work with during the release window, and therefore keep your files in sync. Ultimately, if the files in question don't matter, you can keep them out of the repo, but for many builds, they are indeed necessary, and the best way to keep everything in sync is a planned version upgrade all at once.

Sometime after the preview becomes available, create a preview Scratch Org, deploy everything into it, bump up the API version for your package to the next version, and then pull everything back down again. Doing a planned version change keeps the chaos to a minimum, and using Scratch Orgs ensures that everyone's on the same API version and release.

If you haven't yet seen or heard, the mantra with "Salesforce DX" is that the "repo is the source of truth." This means you shouldn't have to worry about which release an org is on, everything should just work. Of course, that comes with caveats (you obviously can't install 57.0 metadata into a 56.0 org), but managing your versions and org's release version should be exceptionally easy with a bit of discipline.

This is one of those scenarios where Sandboxes should be considered unreliable relative to Scratch Orgs. When you use Sandboxes, you have to pay attention to the Sandbox Refresh schedule, or you might end up on different versions of Salesforce during the release window.

When you use Scratch Orgs, you can specify which version you want to work with during the release window, and therefore keep your files in sync. Ultimately, if the files in question don't matter, you can keep them out of the repo, but for many builds, they are indeed necessary, and the best way to keep everything in sync is a planned version upgrade all at once.

Sometime after the preview becomes available, create a preview Scratch Org, deploy everything into it, bump up the API version for your package to the next version, and then pull everything back down again. Doing a planned version change keeps the chaos to a minimum, and using Scratch Orgs ensures that everyone's on the same API version and release.

If you haven't yet seen or heard, the mantra with "Salesforce DX" is that the "repo is the source of truth." This means you shouldn't have to worry about which release an org is on, everything should just work. Of course, that comes with caveats (you obviously can't install 57.0 metadata into a 56.0 org), but managing your versions and org's release version should be exceptionally easy with a bit of discipline.

Considering we are not making changes to the theme, do these files even need to be in Github in the first place? Or only Site files we anticipate will need changing?

You should strive to be able to recreate an entire org, even if those files won't change. That's how Scratch Orgs are meant to work.

Where are these changes coming from? Is it indeed the Winter release?

Without seeing it, I have do idea. But you should commit those files anyways, once you confirm they work in a Scratch Org.

When these changes happen in the Sandbox, do we need to push them into production?

If they are API-version-related, you'll have to wait until Production is upgraded. You might not need to push them, but the changes should be harmless.