Fix (found in production testing): a command queued behind an ongoing project operation…

v0.19.1-beta

Fix (found in production testing): a command queued behind an ongoing project operation (backup, deployment…) could block indefinitely. The per-project/app lock was a blocking wait with no time limit, ignoring each command's own timeout. Concretely: scaling a container while a backup ran on the same project made the request wait well past the public gateway's timeout (~60s), and the user saw a raw 504 error page instead of a clear message — with the agent never answering on the hub side. Lock acquisition is now bounded (25s): a command that cannot get its lock in time fails immediately with an explicit message ("another operation is already running") instead of waiting silently.