Protect from running parallel commands

[nirs]

Testing with agent shows that they are creative and sometimes ignoring instructions.

We had these cases:

• Cursor running ramenctl validate application for 2 application in parallel. This overload the server and make it hard to present test results.
• Bob running ramenctl test run and ramenctl test clean in parallel after timeout. This creates lot of mess and may lead to 2 processes writing to the same files.

We cannot ensure this does not happen with both agents (ignore instructions) and humans (do not read instructions). The safe way is to ensure that one command is using the output directory at the same time with a lock file.

Locking the output directory

Right after crating the output directory, the command can take an exclusive lock on the directory. Starting second command will fail with a clear message without modifying any file.

Safe commands (e.g. test progress #459) do not ned to take a lock since they do not modify the output directory.

Implementation

lima-vm lockutil uses lock on a directory in a portable way:

• unix: https://github.com/lima-vm/lima/blob/master/pkg/lockutil/lockutil_unix.go
• windows: https://github.com/lima-vm/lima/blob/master/pkg/lockutil/lockutil_windows.go

[caioribeiroclw-pixel]

This lock is the right lower-level fix. It turns the agent problem from "please don't be creative" into a command invariant.

One detail I would make explicit in the lock/error shape: separate writers from watchers.

• test start, test run, test clean, validate ... -o <dir> are writers: take the output-dir lock before touching files.
• test progress from test: Separate running the tests and watching test progress #459 is a watcher: no lock, read-only, safe to retry after harness timeout.
• if a writer lock exists, a second writer should fail before mutating anything and print the current owner + safe next command.

Something like this is enough for debugging without exposing sensitive data:

{
  "output_dir": "test",
  "lock_owner": {
    "command": "ramenctl test start",
    "pid": 12345,
    "started_at": "2026-05-27T16:20:00Z"
  },
  "refused_command": "ramenctl test clean",
  "safe_next": "ramenctl test progress -o test"
}

That gives agents and humans a concrete recovery path. The important acceptance case I’d add: start one writer, then try another writer against the same -o; the second command exits quickly, names the locked output dir, and does not create/modify report files. Then verify test progress can still run while the writer is active.

This pairs well with #459: split long execution into start/progress, then make the output-dir lock the authority for preventing parallel mutation.