Hey,
Similar workflows were sent before too. I don't think there is a specific need for these, gradle dependencies are usually bumped before releases in a single commit and I usually locally test the build before pushing. Same for when updating gradle version. And gradle wrapper scripts don't really need to be updated, at the very least that often that we add a unofficial 3rd party workflow for it.

https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:upgrading_wrapper

Projects will typically want to keep up with the times and upgrade their Gradle version to benefit from new features and improvements. One way to upgrade the Gradle version is manually change the distributionUrl property in the Wrapper’s gradle-wrapper.properties file. The better and recommended option is to run the wrapper task...
Note that running the wrapper task once will update gradle-wrapper.properties only, but leave the wrapper itself in gradle-wrapper.jar untouched. This is usually fine as new versions of Gradle can be run even with ancient wrapper files. If you nevertheless want all the wrapper files to be completely up-to-date, you’ll need to run the wrapper task a second time.

However, if dependabot were to be added, then one would at least have to disable updates for commons-io:commons-io:2.5 with ignored_updates ignore.

Okay.. then I shall remove gradle update workflow and add disable updates for commons-io when I will be free...

Grouped PR are still not supported and won't be released anytime soon. This would create a separate pull request for each dependency update, even for patch (semvar) version updates. A whole lot of PR noise.

Well.. then I shall close this then....

Yeah, sorry, I don't think this is very useful for termux-app. It will likely create more work managing multiple pull requests and syncing with local repo. But if other maintainers think otherwise and want this added, I have no issue with dependabot workflow being merged.