fix(linux): drop ProtectHome=true — blocks exec when binary lives under /home

Integration-linux journalctl showed status=203/EXEC: systemd couldn't
exec /home/runner/work/numa/numa/target/release/numa because
ProtectHome=yes makes /home invisible to the sandboxed process. My
local Docker test passed because the binary was at /workspace, not
/home.

DynamicUser=yes already implies ProtectHome=read-only, which preserves
exec access to binaries living under /home (cargo install, source
builds, CI) while blocking writes to user $HOMEs. Keep that default
rather than over-restricting.

Follow-up worth tracking: install_service_linux could copy the binary
to /usr/local/bin/numa the way Windows does at windows_service_exe_path,
making the unit's ExecStart independent of where `numa install` was
invoked from — then we could set ProtectHome=yes again.

numa.service

@@ -27,7 +27,10 @@ ConfigurationDirectoryMode=0755
 # allow-lists) can be layered on once tested in isolation.
 NoNewPrivileges=true
 ProtectSystem=strict
-ProtectHome=true
+# DynamicUser= sets ProtectHome=read-only by default — leaves /home
+# readable so systemd can exec binaries installed under it (cargo install,
+# source builds), while blocking writes to user $HOMEs. Don't set =yes:
+# that hides /home entirely and fails with status=203/EXEC.
 PrivateTmp=true
 PrivateDevices=true
 ProtectKernelTunables=true