v1.59.0 — target-not-valid-here judges nftables NAT placement too

target-not-valid-here now covers nftables. dnat/redirect only load in a type nat chain at prerouting/output, snat at input/postrouting, masquerade at postrouting — in a filter or route chain never (measured, nftables 1.1.3, ip/ip6/inet: "Could not process rule: Operation not supported", rc 1, and nft -f is atomic). A regular chain is judged by the base chains that reach it, so a hairpin jump from postrouting into a port-forward chain sinks the whole ruleset, even two jumps deep.

The trap: nft -c returned 0 for most of these placements while the real load refused them — a dry run does not catch it. drop/reject in a nat chain load in nft (unlike iptables) and are left alone.

New sample nft-nat-wrong-hook.txt, measured on the file itself: nft -c rc 0, nft -f rc 1 with no table loaded. Tests 368 → 372. (#82)