Merge #264: sshAuthSock is not a control, and the config now says so (#184)

fleetd/fleetd.example.yaml

@@ -676,13 +676,15 @@ guard:
 #            every name here NOT also in `allow` is overlaid with a non-secret sentinel value before
 #            the pane's login shell runs — real protection only for names that shell does not itself
 #            re-export (see the ROUND-2 CORRECTION note above). Under allow-list: reporting only.
-#   sshAuthSock → whether SSH_AUTH_SOCK may pass through under allow-list ("allow") or must be
-#            blanked like any other non-derived name ("block", the default). This is a decision you
-#            have to make explicitly: SSH_AUTH_SOCK is a handle to YOUR ssh-agent, and a member
-#            holding it can sign with your keys — it sits in no secret file and looks like no
-#            credential, which is why it slipped past three earlier tickets (gitea #110). Blocking
-#            it breaks git over SSH inside members (push/fetch authenticate as you); use HTTPS
-#            remotes or scoped deploy keys instead of allowing it lightly.
+#   sshAuthSock → whether SSH_AUTH_SOCK may pass through under allow-list ("allow") or is omitted
+#            from the member environment ("block", the default). Blocking it only omits the
+#            inherited ssh-agent path. It discourages automatic use of the operator's agent.
+#            It does not deny same-user access to that socket. It also does not block SSH keys that
+#            are readable on disk. Git over SSH may still work from inside a member. Keep the block:
+#            it is correct and costs nothing, but it is not a control. A member runs as the same OS
+#            user as the lead. Inside one uid, ordinary Unix permissions provide no meaningful
+#            confidentiality boundary. A real boundary needs a different OS user or OS-level
+#            confinement, such as a container or VM. That is the open question in fleetd #184.
 #
 # HOT-RELOADABLE the same way `fleet:` is (CB-559): read fresh on every spawn, so editing this list
 # and reloading config (or restarting) changes what the NEXT spawn inherits; already-running members