whether the next packet of communication will be sent over the same connection or not
Nearly but not exactly. There is not "packet" at this level of communication, just a data stream. HTTP-Keep-alive will allow multiple HTTP requests over the same TCP/TLS connection instead of only one by not closing the connection immediately after the HTTP response but instead keeping it open for more requests.
HTTP Keep-Alive header dictates
No, it dictates nothing. By adding Connection: keep-alive to the query (or implicitly by using HTTP/1.1 instead of HTTP/1.0) the client is asking the server politely to not close the TCP connection after the response is done. The server might agree or it might not.
any client-server communication will take place over the same connection
Not necessarily. There might be multiple TCP/TLS connections open in parallel between browser and server.
any client-server communication after 60 seconds of inactivity will reinitiate the SSL handshake and then proceed with requests and repsonses.
Client and server can decide to close the idle connection (i.e. no outstanding response) at any time and both have their independent settings and timers. If the connection is closed and the client wants to make a new request it needs to create a new TCP connection and for HTTPS it needs either to resume an existing SSL session on top of this TCP connection or to do a full TLS handshake for a new SSL session.
Also, how is this connected to a user's session inactivity timeout?
This is completely unrelated. User sessions are managed at the application level. HTTP keep alive is managed at the HTTP protocol level. You can have multiple user sessions within a single TCP connection (with multiple HTTP requests) and you can also have a user session be kept over multiple TCP connections (both after each other and also parallel connections).