I may have figured this, at least in part - no definitive solution, though.
Experimenting with tcdump, while pinging from my workstation to another box inside the remote network (at 192.168.1.2), via my TN WG server (at 192.168.1.8), I've found out that the ping source IP is not NAT'ed - it is passed along unchanged with the source IP on my workstation peer config (10.225.30.6):
13:17:08.029844 IP 10.225.30.6 > 192.168.1.2: ICMP echo request, id 1, seq 78, length 40
13:17:08.029897 IP 192.168.1.2 > 10.225.30.6: ICMP echo reply, id 1, seq 78, length 40
However, that box has no idea how to route back to my peer IP, via the WG server, and so the replies are sent to the default gateway and subsequently discarded.
If I manually add a route to this other box (at 192.168.1.2) for the peer subnet, using as a gateway the WG server (192.168.1.8)
route add 10.225.30.0/24 192.168.1.8
Then the ICMP replies get back correctly to my workstation.
This does not happen when WireGuard runs inside a jail or VM: the packets are NAT'ed with the local IP address of the server; compare the example above with the same test while running WG inside a jail, properly translating the source IP on my workstation peer config (10.225.30.6) to the IP on the WG server (192.168.1.8)
13:46:51.227567 IP 192.168.1.8 > 192.168.1.2: ICMP echo request, id 1, seq 83, length 40
13:46:51.228499 IP 192.168.1.2 > 192.168.1.8: ICMP echo reply, id 1, seq 83, length 40
There must be some additional config to enable NAT when using the native WireGuard implementation on TrueNAS, and I'll try to find out the proper commands to do so...
Is my interpretation of the issue correct, or am I missing something?
Edit: I understand that you can add a static route pointing the WG peer subnet [10.225.30.0/24] back to the IP of the WG server [192.168.1.8], but some ISP routers here in Brazil do not allow that - a solution that uses NAT, if indeed possible, works better for me.