Issue 149: whose the data is, not only where

The media modules must run as the owner of the data they access; the data
already says who that is. Proposes ${access:<id>:uid|gid} instead of user
management in the mesh (ADR 0051).

04-ISSUES/149-an-adopted-machines-data-cannot-be-placed-where-it-is/00-report.md

@@ -55,3 +55,17 @@ The two assignment halves 0112 decided: a setting that places a declared directo
 path on this node, and a setting that says where an access's data is — both validated like
 `endpoints` (unknown ids refused), and an access placed by the assignment still never created,
 chowned or removed.
+
+## Addendum 2026-09-30 — whose the data is, not only where
+
+The same modules need to run **as the owner of the data they access**: linuxserver images take
+`PUID`/`PGID`, and ace's library is `media:media` (`1001:2000`, group members `ace`, `n8n`, `media`).
+A manifest default is one value for every machine, and an assignment's settings do not reach a
+container's environment. Adding user and group management to the mesh would contradict ADR 0051 —
+the mesh owns nothing about the operator's data.
+
+The data already says whose it is, and the host already looks at it when it confirms an access exists.
+Proposed: expose that as a fact the module can ask for, like `${port:…}` — e.g. `${access:<id>:uid}`
+and `${access:<id>:gid}`, read from the accessed path on the machine — so a media module declares
+`PUID=${access:media:uid}` and is right on every machine without the mesh creating, naming or
+chowning anyone.