Since in a generic case, there may be multiple peers associated to a single Wireguard interface, it doesn’t seem a good idea to change the interface state to inactive when a single peer goes down (even though in your case this single peer is the only one associated to that interface).
Hence if you need to deactivate the route via that peer if connection to that peer is down (and bear in mind that many people want the opposite, i.e. that traffic that should go via VPN doesn’t leak in plaintext if the VPN doesn’t work), you need to check the transparency of the tunnel using the same means like in case of WAN failover - using /tool netwatch, a combination of /system scheduler and /system script, or recursive routing.