fix(manager): avoid cp -a preserve ownership failure on NFS workspaces

[LUOSENGWA]

Problem

When the Manager workspace is mounted from NFS (or any filesystem where the container user cannot chown to root), the plugin copy step in start-qwenpaw-manager.sh fails:

cp: failed to preserve ownership for '.../plugins/agentteams-manager-tools/plugin.json': Operation not permitted

Because set -e is active (in manager/scripts/lib/base.sh and agentteams-env.sh), the failure aborts the entire Manager startup → the Manager enters a crash loop. The agentteams-manager-tools plugin (projectflow / taskflow / message / filesync) is never installed.

Root cause: cp -a (== --preserve=all) includes --preserve=ownership, which attempts to chown the copied files to the source owner (root). On NFS with root-squash or maproot to a non-root user, the container root cannot chown to uid 0 → Operation not permitted → cp exits non-zero → set -e aborts startup.

问题

当 Manager 工作区挂载自 NFS（或任何容器用户无法 chown 到 root 的文件系统）时，start-qwenpaw-manager.sh 中的插件复制步骤会失败：

cp: failed to preserve ownership for '.../plugins/agentteams-manager-tools/plugin.json': Operation not permitted

由于 set -e 处于启用状态（manager/scripts/lib/base.sh 与 agentteams-env.sh），失败会中止整个 Manager 启动流程 → Manager 进入崩溃循环。agentteams-manager-tools 插件（projectflow / taskflow / message / filesync）永远无法安装。

根因：cp -a（等价于 --preserve=all）包含 --preserve=ownership，它会尝试将复制后的文件 chown 为源属主（root）。在启用 root-squash 或将 maproot 映射到非 root 用户的 NFS 上，容器内 root 无法 chown 到 uid 0 → Operation not permitted → cp 非零退出 → set -e 中止启动。

Fix

Copy plugins without preserving ownership:

-        cp -a "${_plugin_src}" "${PLUGINS_TARGET}/${_plugin_name}"
+        cp -a --no-preserve=ownership "${_plugin_src}" "${PLUGINS_TARGET}/${_plugin_name}"

The plugin files keep the container user's ownership (readable by the QwenPaw PluginLoader); timestamps/modes/links are still preserved. Note the option order matters: cp --no-preserve=ownership -a would be overridden by -a (which expands to --preserve=all), so --no-preserve=ownership must come after -a.

修复

复制插件时不保留属主：

-        cp -a "${_plugin_src}" "${PLUGINS_TARGET}/${_plugin_name}"
+        cp -a --no-preserve=ownership "${_plugin_src}" "${PLUGINS_TARGET}/${_plugin_name}"

插件文件保留容器用户的属主（QwenPaw PluginLoader 可读）；时间戳/权限/链接仍然保留。注意选项顺序很关键：cp --no-preserve=ownership -a 会被 -a（展开为 --preserve=all）覆盖，所以 --no-preserve=ownership 必须放在 -a 之后。

Testing

• Existing CI (Manager boot / tests).
• Manual: Manager workspace on NFS with maproot to a non-root user — plugin install succeeds, Manager starts.
• Without the fix, the same environment fails with cp: failed to preserve ownership and the Manager exits.

测试

• 现有 CI（Manager 启动 / 测试）。
• 手动验证：Manager 工作区位于 NFS 且 maproot 映射到非 root 用户时 — 插件安装成功，Manager 正常启动。
• 未应用修复时，同一环境会报 cp: failed to preserve ownership 且 Manager 退出。

[LUOSENGWA]

The integration-tests (controller-cr, SHARD_C_TESTS, copaw, copaw, false) job failed on test-19-human-and-team-admin. Based on the logs, we believe this is a pre-existing flaky test (Team reconciler delete/create timing race), not caused by this PR:

• This PR only changes one line in manager/scripts/init/start-qwenpaw-manager.sh (cp -a → cp -a --no-preserve=ownership). The failing shard runs the copaw manager runtime, which does not load start-qwenpaw-manager.sh at all — zero overlap with the change.
• The same test passed in the other three parallel shards in this run: copaw/hermes, copaw/qwenpaw, openclaw/openclaw (all ~28s).
• The failure mode matches the known flake: Team test-hadm-45946 never reached Active within 180s, agt get team returned HTTP 404: get team: not found, and the Team reconciler logged no processing for it — while the Worker/Human reconcilers worked fine. The same test failed the same way on PR fix(qwenpaw): propagate model capabilities to QwenPaw worker #1158 (8/8) in an openclaw shard, also unrelated to that PR's changes.

A re-run of the failed job would likely pass. If it reproduces consistently, it may be worth filing an upstream issue for the Team reconciler delete/create timing race.

Thanks!

integration-tests (controller-cr, SHARD_C_TESTS, copaw, copaw, false) 这个 job 在 test-19-human-and-team-admin 上失败了。根据日志，我们认为这是预先存在的 flaky 测试（Team reconciler 删除/创建时序竞态），不是本 PR 引入的：

• 本 PR 只改了 manager/scripts/init/start-qwenpaw-manager.sh 一行（cp -a → cp -a --no-preserve=ownership）。失败的 shard 跑的是 copaw manager runtime，根本不会加载 start-qwenpaw-manager.sh —— 与改动零交集。
• 本次运行中另外三个并行 shard 的同一测试全部通过：copaw/hermes、copaw/qwenpaw、openclaw/openclaw（各约 28 秒）。
• 失败模式与已知 flake 一致：Team test-hadm-45946 180 秒内未到达 Active，agt get team 返回 HTTP 404: get team: not found，Team reconciler 对该 Team 零处理——而 Worker/Human reconciler 工作正常。同一测试在 8/8 的 PR fix(qwenpaw): propagate model capabilities to QwenPaw worker #1158 上也以同样方式失败（openclaw shard），同样与该 PR 的改动无关。

重新运行失败的 job 大概率能通过。如果持续复现，可能值得为 Team reconciler 的删除/创建时序竞态提一个上游 issue。

谢谢！