Rerun the fetch step to produce a new v26.1 of protocolbuffers/wellknowntypes

[jhump]

This runs the latest fixes in #530 to pull in the cpp_features.proto and java_features.proto files into the v26.1 module.

This is currently just a draft PR because we need to double-check exactly whether this will work or not. It looks like it should work fine with the daily "release" process, which effectively rsyncs the modules directory of this repo to a GCS bucket. The question is whether the "sync" process run inside each BSR instance will work correctly with it. We need to verify what their behavior is in the face of a tag that changes in a state.json file. It is technically possible for it to push the new version and then update the tag, to move it to the newer commit. But it needs to be confirmed whether the "sync" logic will do that.

[jhump]

@pkwarren, what do you want to do with this PR? On the one hand, the obvious choice might be to just close it since we know it won't have any impact on the sync process and will never get picked up into an existing BSR instance.

However, if we go ahead and merge it:

1. Any newly-provisioned BSR instances will get the corrected content. (At least I think so.) That could be a good thing, since it means some instances have the right stuff. (Admittedly, the potential drawback is that it could be confusing, if someone else happens to notice that their instance content doesn't match, for example, the public buf.build instance's version of it.)
2. It also means we don't have to remember to go re-compute this state again in the future, once the BSR sync process is fixed. Once the sync process is updated/improved, this tag of this module will immediately be fixed in each instance.

WDYT?

[pkwarren]

@pkwarren, what do you want to do with this PR?

I'd like to leave this in draft for now - once we've discussed further how to potentially improve the syncer to re-sync the latest commits, we could merge this. Until then I think it would be confusing if the state differs between instances or what is stored here doesn't match what is synced in other clusters.

[jhump]

Closing. Now that there is a v27.0 of this module, it's a little trickier to get it sync'ed to all BSRs. And v27.0 has the correct set of files, so it's not really urgent that we have these files in this version anyway. If we change our mind and want to fix this version in the future (which feels pretty unlikely), it would be easy to resurrect the contents of this PR.