Say the login session a mesh-cli line comes from, and pin the SDK at go/v0.1.9 (hq ADR 0272)

A service running as the operator — the tool runner, a unit of the
account's user manager — shares the operator's user id, and was as much the
terminal on the control-node as a person typing. The engine now 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 nothing else the terminal. The SDK is pinned at its
tag now that go/v0.1.9 exists.

README.md

@@ -159,6 +159,11 @@ controller decides what the line may do, and the engine runs nothing it receives
 connection's deadline set the moment it is accepted, two lines at once per account and eight for the machine,
 "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
+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.
+
 **A process outside the machine's own namespaces is refused**, whatever its user id: the peer's mount and user
 namespace must be the engine's. So `mesh-cli` run inside a flatpak, a toolbox or distrobox container, or any other
 container — even one running as the operator's own id — is refused with the reason; run it from the machine's own