PuTTY keepalive limits: SSH null packets vs TCP keepalives for idle sessions behind NAT

I run long-lived SSH sessions from PuTTY through a home NAT router, and idle sessions are dropped after some period of inactivity. PuTTY's Connection panel offers two distinct mechanisms: "Seconds between keepalives", which sends SSH-level null packets, and "Enable TCP keepalives", which relies on the OS socket layer.

My understanding is that the null-packet option defaults to 0 (disabled), only fires while the connection is otherwise idle, and is stored per saved session, while TCP keepalive timing is governed by OS defaults that can be hours on Windows. What I cannot resolve is which mechanism actually resets the NAT's idle timer in practice, and whether enabling both is redundant or harmful.

Constraints: I want to avoid masking genuine outages with an overly aggressive interval, and I would prefer not to tune Windows registry values for TCP keepalives if the application-level option suffices.

1. Does the SSH-level null-packet keepalive reliably reset NAT and firewall idle timers where TCP keepalives do not?
2. Is there any downside to enabling both options at once, or is one strictly sufficient?
3. What interval is a reasonable lower bound before keepalive traffic itself becomes a problem on metered links?