You're having difficulty with the concept because there isn't such a concept. Process groups can be in the background/foreground. The concept does not apply to sessions, neither what the operating system calls sessions nor what
tmux calls sessions, which are two very different things.
tmux does is create one or more pseudo-terminals, which the programs running within
tmux see as their controlling terminals (and standard inputs, outputs, and errors to start with). It multiplexes those inner terminals onto a single outer terminal, which will be the pseudo-terminal set up by the SSH server on your machine when you logged in over SSH.
There are two
tmux processes, a long-lived server that connects to the back ends (i.e. "master" sides, to use a no longer fashionable terminology) of all of those inner pseudo-terminals, and a client that is the intermediary between that server and the realized-upon outer terminal. Actually, there can be multiple clients, but that is a complexity that we can gloss over here, as it does not change the point.
The server process exists as long as there is at least one inner pseudo-terminal remaining. It groups the pseudo-terminals into collections, which are what
tmux calls sessions. That is not to be confused with what your operating system calls a session (a collection of process groups and optionally a controlling terminal), or a session over SSH (between the remote SSH server and your local SSH client). "session" can denote a lot of different things. Notice that I'm variously qualifying it with "
tmux", "SSH", and "operating system" here.
The client process is transient, and goes away — detaching from the
tmux session and server — with the loss of the SSH connection. When you log-in afresh with SSH, you create a new client that re-attaches to (a
tmux session managed by) the server, and that new client realizes the user interface of the
tmux server — all of the windows in the
tmux session and the status line — onto the fresh pseudo-terminal for your new SSH login session. A client realizes one
tmux session at a time, the one to which it is currently attached.
The client process is a part of what the operating system calls a session, the session that is controlled by the outer pseudo-terminal created by your SSH server for SSH login. It is subject to the lifetime of that operating system session, which is in turn subject to the lifetime of the SSH session, and can be in the background or foreground process group of that outer terminal. It is (thereby) subject to shell job-control of the login shell of that SSH session.
The server process is entirely divorced from the outer terminal and its operating system session(s). It is not subject to their lifetimes. It is not in their background or foreground process groups. Its lifetime is solely determined by the continued existence of inner terminals, whose I/O it serves up to
There are inner and outer terminals. There are attached and detached
tmux sessions, by extension from clients attaching to and detaching from
tmux servers. There are active and inactive windows within a
tmux session. The shell job-control concept of background and foreground is not involved.