Your firewall should be configured to restrict the traffic to the web server port to eth0. You should do this independently and regardless of any other patches.
I use lighttpd on an industrial control system based on Linux. I have two network ports (configurable by the customer). To ensure that only the first network port (eth0) can be used to connect to the web server, I currently have to set the server.bind option to the IP address of eth0. But I don't know the address, so this option doesn't work for me.
Various parts of lighttpd code need to know the address and as you found, lighttpd expects the lighttpd.conf to tell lighttpd the address. (While lighttpd could write code for discovery, that would be extra code in "light" lighttpd.)
Multiple solutions are already available for you to implement your own arbitrary logic and bind to the listening socket yourself.
Your lighttpd startup script could determine the IP address before starting lighttpd and could set an environment variable which is used in lighttpd.conf.
Alternatively, your startup script could bind to whatever you like, and then pass the listening socket to lighttpd.
server.systemd-socket-activation = "enable" allows you to use this systemd feature, or to implement similar logic yourself if you do not use systemd.
lighttpd -h
xinetd
allows you to configure lighttpd to listen on the socket already listening on stdin.
Not recommended, but lighttpd has limited support for ipv6 scoped literals in the listening socket.
See prior discussions in #2442, #2218, and https://redmine.lighttpd.net/boards/3/topics/10038
Regarding your patch, lighttpd provides multiple ways to configure listening socket in lighttpd.conf, and your patch is very specific to your use case configuring the primary listening socket in the global scope. This is inconsistent or unspecified with other ways to specify and configure listening sockets in lighttpd, e.g. $SERVER["socket"] = "...". Would server.interface config be inherited by other $SERVER["socket"]? Setting to a blank string would not undo the setting, due to the way you have coded the patch. The patch could be adjusted, but...
In any case, I am currently not convinced that your patch adds a necessary feature in a way that is better than the existing options that I noted above. If you still think your patch is a good solution, please explain why you are unable to use the other options I noted above.