The linux kernel does not automatically close a TCP connection if it's idle, it can stay idle for years on end (unless you globally enable TCP keepalives, or some NAT/stateful firewall devices inbetween times it out).
What's happening is not that your client is creating a new TCP connection and resumes an SSH session, you are just and continuing on your existing SSH session over an existing TCP connection - which you can do as long as neither the client ssh process or server sshd process have been restarted, and neither end has attempted and failed to send any data or otherwise timed/errored out the TCP connection.
(e.g. if you did a (sleep 60 ; echo test)& , then went hibernate on your client side, the server side would attempt to send some output in 60 seconds, and eventually time out the connection after a few minutes unless you wake up in the mean time)
I did some hands-on research, and I now agree that you are correct. The behavior is absolutely acting like a resumption of the TCP session, not extra connectivity magic within SSHD.
Thanks for the persistence!
That said, though, there is something which closes idle, established, TCP connections, though it's not the kernel, it's iptables which does it. The timeout is something along the lines of 5 days by default, however. That's what I get for working from memory.
No, there isn't, TCP is end-to-end, and can only be closed by the endpoints.
If you use iptables (or rather netfilter)'s stateful filter, then netfilter will forget the connection tracking state of the connection after a long-ish time without any traffic (may be 5 days, I don't remember). That doesn't close anything, it simply means that netfilter doesn't know about the connection anymore. No packets are being sent when that happens.
That in turn has two effects:
First, if you have a rule that only allows packets through for established connections, that rule will now not match packets from that connection anymore. But if the packet matches another rule that allows it to pass, then it will still make it through the firewall, and as a side effect that would then re-establish the connection tracking state, which in turn would also make the rule for established connections match again for any packets that follow.
So, in most cases, that's not in any way a problem: The next packet your client sends after a long idle time will just re-establish the connection tracking state and the connection will continue to work just fine.
Second, if the connection is NATted, the NAT state is part of the connection tracking state, and as such, the NAT mapping of the connection is also lost when the state is dropped. That means that the next packet (if it comes from the right direction) will once again consult the nat table, just as the very first packet of the connection, to establish a new NAT mapping. Now, in many cases, that will establish a new mapping that's exactly the same as the old mapping, in which case the connection also will continue to work just fine. Only if the new NAT mapping differs, that will cause the connection to fail. Yet another reason why you don't want to have NAT (and by extension, why you want IPv6).
What's happening is not that your client is creating a new TCP connection and resumes an SSH session, you are just and continuing on your existing SSH session over an existing TCP connection - which you can do as long as neither the client ssh process or server sshd process have been restarted, and neither end has attempted and failed to send any data or otherwise timed/errored out the TCP connection.
(e.g. if you did a (sleep 60 ; echo test)& , then went hibernate on your client side, the server side would attempt to send some output in 60 seconds, and eventually time out the connection after a few minutes unless you wake up in the mean time)