Looks really great!

The only thing that comes to mind is reproducible builds are only useful to detect injection if someone actually tries to reproduce the builds. Bystander effect says no one likely is, so adding a separate (perhaps GitHub Actions?) build to confirm an identical tarball SHA would remove the possibility that your own environment is compromised.

Have multiple maintainers/community members sign the tarballs. As things stand now the confidentiality of your lone key stands between a modified tarball being published and potentially not caught for a while. That modified tarball will not match git but users pretty much never compare the tarball to git. When the other maintainers/community members sign for the release they can compare the tarball to git and use their signature to assert that the tarball matches git. Users that do verify signatures will notice if only one signature is there or if all the signatures don't match and it will start being investigated, potentially reducing the scope/timeframe of the compromise.

I helped design the Subversion project's release process and the project does this. Releases require a certain number of votes/signatures and the release announcement has a list of who signed and the fingerprints for their keys. You can see that project documentation for the signing here: subversion.apache.org/docs/com… You can see an example of a release announcement which is made on the announce mailing list and is mirrored here: lists.apache.org/thread/gcbmxz…

Subversion doesn't produce official builds but if they did and had reproducible builds then builds could be reproduced and folks verifying that the builds match the tarball/git could provide signatures for them as well. Which would help resolve @sethmlarson's point about reproducible builds not being helpful unless someone is trying to reproduce them.