MCP lifecycle lock can mutate state after acquisition timeout #7858

Investigation Summary

• cli-test-shards (4) on PR fix(onboard): rebuild on messaging credential drift #7853 failed at test/mcp-lifecycle-lock.test.ts:436 because a corrupt lock disappeared after the acquisition had already timed out.
• Current main checks the timeout only at the start of each acquisition-loop iteration.
• An asynchronous lock observation can start before the deadline, resume after both the deadline and corrupt-lock grace, then reap the existing lock before the next timeout check.
• The same gap can publish a new lock before the deadline but enter the critical section after it.
• No open issue or PR matching this deadline contract was found.

Description

MCP lifecycle-lock acquisition can still mutate lock state after its timeout budget has expired.

The acquisition loop checks elapsed time at the beginning of an iteration. Filesystem reads, links, and identity observations then run asynchronously. If one of those operations is delayed, the iteration can cross the deadline and still:

1. create a stale-lock reaper and delete an existing corrupt lock, or
2. publish a new lock and enter the protected operation.

The timeout should be a fail-closed boundary: after the deadline, acquisition must not remove a pre-existing lock or enter the critical section. If the caller's own lock generation was published just before the deadline was detected, NemoClaw should release only that generation and return the existing timeout error.

Observed CI evidence:

• PR: fix(onboard): rebuild on messaging credential drift #7853
• Exact head: 8d144240adabbbe36901a32dd633af8312203a27
• Failed job: cli-test-shards (4) / job 90742116177
• Failure: ENOENT reading the corrupt lock immediately after the expected timeout rejection

Reproduction Steps

1. Create a malformed MCP lifecycle lock for a sandbox.
2. Start acquisition with a timeout shorter than the corrupt-lock grace period.
3. Delay an asynchronous observation after the iteration's timeout check until the monotonic clock is beyond both the acquisition deadline and corrupt-lock grace.
4. Observe that current main can classify and reap the lock before the next loop-level timeout check.
5. Repeat with an absent lock and delay deadline observation until after the atomic link; current main can return the acquired lock and run the callback after the deadline.

A deterministic regression test can inject a monotonic clock to model both boundaries without relying on runner scheduling.

Environment

• OS observed in CI: Ubuntu 24.04.4, x86_64
• Node.js: repository CI version
• NemoClaw: main at d52d4599a18490e7f8efc6e8062296fffcbea4a7
• Affected subsystem: host-side MCP lifecycle lock acquisition

Debug Output

Error: ENOENT: no such file or directory, open '.../mcp-lifecycle-locks/8ed3f6ad...lock'
  at test/mcp-lifecycle-lock.test.ts:436:15

Checklist

• I confirmed this bug with exact-head CI evidence and a deterministic clock-controlled regression.
• I searched existing issues and pull requests and found no duplicate.