login: fix user@.service case, so we don't allow nested sessions (#8051)

> logind sessions are mostly bound to the audit session concept, and audit
> sessions remain unaffected by "su", in fact they are defined to be
> "sealed off", i.e. in a way that if a process entered a session once, it
> will always stay with it, and so will its children, i.e. the only way to
> get a new session is by forking off something off PID 1 (or something
> similar) that never has been part of a session.

The code had a gap.  user@.service is a special case PAM session which does
not create a logind session.  Let's remember to check for it.

Fixes #8021