The organization concurrency test fails with Busy when the machine is heavily loaded

organization::tests::concurrent_updates_do_not_lose_each_other (crates/storage/src/organization.rs) fails with update: Busy { path: ".../data/organization.lock" } when the machine is heavily loaded.

The test starts eight threads that each call Organization::update. Each update takes the organization lock through FileGuard::take with ORGANIZATION_LOCK_PATIENCE (five seconds). Under enough load a waiting thread does not get the lock in that time and gets Busy, so the test panics.

Seen while cargo test --workspace ran next to a CI run and other builds (load average above 200): it failed once in the workspace run, and once in 15 repeated runs of the test alone. It passes in the normal case, including in an earlier full workspace run on the same code, so this is not a regression of the code under test.

Expected: the test does not depend on the lock being granted within five seconds on a machine under load, for example by giving the guard more patience in tests, or by the test tolerating Busy and retrying. Check whether a real caller can hit the same five-second limit before choosing, because the lock is also taken by the interface and the CLI.