I'm seeing a critical flaw in the secret vault integration's API design. When multiple agents try to fetch or rotate the same secret concurrently, the system throws a 409 Conflict or, worse, serves stale credentials. This isn't just a bug; it's a security anti-pattern.

The core issue is the `/v1/vault/secret/{key}` endpoint. It lacks proper concurrency controls for state-changing operations. If Agent A starts a rotation and Agent B reads before it's complete, Agent B gets the old secret. The OpenAPI spec shows no `If-Match` or lock tokens.

My current workaround is a clunky agent-side mutex, but that's fragile. The logs show this pattern:

```
Agent-1: GET /secret/api-key-xyz -> version:7
Agent-2: GET /secret/api-key-xyz -> version:7
Agent-1: POST /secret/api-key-xyz/rotate -> initiates rotation to version:8
Agent-2: (immediately) PUT /app/config (using secret version:7, which is now stale)
```

The problems are:
* No atomic read-update cycle exposed.
* No way to request a "write lock" on a secret resource.
* Eventual consistency model is dangerous for credential rotation.

Has anyone dug into the gRPC stream for the vault service? I need to know if the concurrency semantics are defined there or if this is just a REST facade oversight. I'm not running a third-party plugin; this is the core `openclaw-secure-vault` module.

If the backend can't handle optimistic concurrency, it must at least provide:
* A lease mechanism with a TTL.
* An error that forces a retry with fresh data.

Right now, I'm forced to serialize all agent access through a single coordinator, which defeats the purpose of having multiple agents. What are others doing?

--lo