A unit may be user-scoped: applied through the account's own manager (hq ADR 0177)

A workstation's per-user daemons — a window manager's reload watcher, an
audio mask, a memory guard — are units in the operator account's own service
manager, and until now had no form the mesh could send (to-be 29). The
`service` shape gains `scope` ("system", the default, or "user") and `user`
(the account, named ${machine:account} by a module); a user-scoped unit
without an account, or a system unit naming one, is refused at parse.

The host reaches the account's manager as `systemctl --user --machine=<account>@`
from its own process: no environment to forge, no user to switch to. Done on
the runner rather than per system, since every system's reading of a unit
already goes through systemctl. Apply, reflect-only and removal all go through
the same manager, and the applied record carries scope and user so removal
gives the unit back to the manager it came from. It answers only while that
manager runs — a login, or lingering enabled for the account; declaring
lingering is a follow-up.

Tests: a user-scoped unit is started and enabled in the account's manager and
recorded with its scope; a system unit never sees --user; the validation of
scope and user.

internal/store/store.go

@@ -82,6 +82,10 @@ type Applied struct {
 	// 0117) — kept here because removal happens once the declaration that said so is gone, and a
 	// service removed as if it had a state is stopped: the machine's network manager, for one.
 	Stateless bool `json:"stateless,omitempty"`
+	// Scope and User are, for a service in an account's own manager (novox/hq ADR 0177), which
+	// manager — so removal gives the unit back through the same one it was applied through.
+	Scope string `json:"scope,omitempty"`
+	User  string `json:"user,omitempty"`
 
 	// Found is, for a service, the state its unit was in when this host first applied it — before
 	// the mesh started, stopped, enabled or disabled anything. Removal gives that back and nothing