Codex review: needs maintainer review before merge.

Summary
The PR exports the existing PID ancestry walker, uses it in openclaw update to abort package-manager updates when the active Gateway runtime PID is in the caller ancestry, adds a CLI regression test, and updates the changelog.

Reproducibility: yes. #75691 gives a concrete systemd plus agent-exec no-marker path, and current main source still stops/updates based on service state without checking whether the active Gateway PID is in the caller ancestry.

Next step before merge
No repair job: the branch already contains the focused code, test, and changelog changes; remaining work is normal maintainer review plus exact-head CI/rebase reconciliation.

Security
Cleared: The diff changes updater control flow and exports an existing internal PID helper, with no new dependency, workflow, package-source, secret-handling, or supply-chain execution surface.

I reviewed/tested the related service-marker approach and found the critical lifecycle risk in live VPS testing: an updater launched from a Gateway-owned exec lane can stop the service that owns its process tree and then be SIGTERM’d before package replacement/restart completes.

This PR fixes the underlying #75691 failure mode more directly by blocking before any service stop or package mutation when the active Gateway PID appears in the caller’s PPID ancestry.

Live proof: targeted tests passed for src/cli/update-cli.test.ts and src/infra/restart-stale-pids.test.ts; then a real Gateway-owned agent exec ran with service-marker env explicitly unset and reported self=1447931 ppid=1443416 gateway_pid=1443416. openclaw update exited 1 with openclaw update detected it is running inside the gateway process tree, and the Gateway stayed healthy afterward: MainPID=1443416 ActiveState=active SubState=running.

So this is intentionally narrower than the service-marker PR: it does not try to redesign the post-core marker/runtime-state flow, it just closes the unsafe in-lane update path before the Gateway can kill its own updater.

Live VPS validation on commit 44fb7668ce:

• Gateway before repro: MainPID=1443416 ActiveState=active SubState=running.
• Targeted tests passed: pnpm test src/cli/update-cli.test.ts src/infra/restart-stale-pids.test.ts -- --reporter=verbose.
• Test details: src/infra/restart-stale-pids.test.ts passed 48 tests; src/cli/update-cli.test.ts passed 69 tests; total 2 Vitest shards passed in 11.18s.
• Gateway path sanity check passed: openclaw agent --agent main --message 'Reply with OK only.' returned OK.
• Strict no-marker live repro ran from a real Gateway-owned agent exec with OPENCLAW_SERVICE_MARKER and OPENCLAW_SERVICE_KIND unset.
• Repro process proof: self=1455610 ppid=1443416 gateway_pid=1443416.
• openclaw update exited 1 with openclaw update detected it is running inside the gateway process tree.
• Gateway after repro stayed healthy: MainPID=1443416 ActiveState=active SubState=running.

This validates the #75691 failure mode directly: a package update launched from inside the active Gateway process tree is refused before service stop/package mutation, so the Gateway does not kill the updater or keep running stale code silently.

Thanks for opening this and for the live VPS proof.

My read is that this PR is not a duplicate of #75729. They cover related but different safety signals:

• fix(cli): block package updates from inside running gateway service #75729 covers the service-marker/runtime-state path.
• This PR covers the no-marker PPID-ancestry path where the updater is still owned by the active Gateway process tree.

Plan from my side:

1. Land fix(cli): block package updates from inside running gateway service #75729 first, since it is the broader service-marker/runtime-state guard and has already absorbed the review feedback there.
2. Rebase this PR on top of fix(cli): block package updates from inside running gateway service #75729.
3. Keep the PPID-ancestry guard from this PR, add the requested changelog entry, and then proceed with review/merge.

So please keep this PR open. After rebase, it should remain intentionally narrow: block restartful package updates before service stop/package replacement when the active Gateway PID appears in the caller ancestry.

Merged via squash.

• Prepared head SHA: acdf73e6d0b6172107919d368a6f520041ae80a8
• Merge commit: c81c0171cd2796556495628c143cbdf64e8badbc

Thanks @ai-hpc!