A login session is the account's own, of class user, read at accept (hq ADR 0272)

The cgroup names a scope; only logind's record of it says whose session it
is. The engine now takes a session only when /run/systemd/sessions/<id>
says it is this account's (UID), of class user (not a greeter's or the
user manager's), and of this very scope. And it reads the session the
moment the connection is accepted, with the namespaces, before the line,
so the peer is judged as it was when it connected.

Tests: session-9.scope with a user record is taken; x.scope, a different
uid, another account's session, a greeter's, a record naming another
scope, no record, and a path with dots are not; the session is read
before the line is forwarded.

README.md

@@ -160,7 +160,9 @@ connection's deadline set the moment it is accepted, two lines at once per accou
 "busy" beyond that.
 
 **Only a login session can be the terminal.** The engine reads the asking process's cgroup and sends its login
-session's scope (`session-<id>.scope` under the account's own `user-<uid>.slice`), or nothing; the controller makes
+session's scope (`session-<id>.scope` under the account's own `user-<uid>.slice`, which logind's own record in
+`/run/systemd/sessions/<id>` must say is this account's, of class `user`), or nothing, read the moment the
+connection is accepted; the controller makes
 nothing else the terminal. A service running as the operator — the tool runner, a unit of the account's user
 manager — is at most an ordinary call.