Scripts using #!/bin/sh instead of #!/usr/bin/env (ba)sh won't use your shiny new shell. Including scripts deep inside the build system of misc. software that you won't modify.
The only way is to set their strange /etc/private symlink (cf sh(1)) to change what /bin/sh execs, and to do it again after each update which resets it.
I wonder what is the origin of this "/bin/sh" and why it's often assumed that sh is in /bin by default. The standard is pretty clear about that:
"Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in."
"Furthermore, on systems that support executable scripts (the "#!" construct), it is recommended that applications using executable scripts install them using getconf PATH to determine the shell pathname and update the "#!" script appropriately as it is being installed (for example, with sed)."
So, apparently on systems, where sh resides in /bin, "getconf CONF" will return /bin . However, this is not always the case. For example, on my Fedora Linux it is /usr/bin
$ getconf PATH
/usr/bin
$ ls -l /usr/bin/sh
lrwxrwxrwx. 1 root root 4 Jan 2 2023 /usr/bin/sh -> bash
$ ls -l /bin/sh
lrwxrwxrwx. 1 root root 4 Jan 2 2023 /bin/sh -> bash
$ ls -ld /bin
lrwxrwxrwx. 1 root root 7 Aug 9 2022 /bin -> usr/bin
The only way is to set their strange /etc/private symlink (cf sh(1)) to change what /bin/sh execs, and to do it again after each update which resets it.