fix(daemon): emit tracing around project lock acquire (#346) (#350)

Daemon state transitions to "Building" via OperationGuard *before*
the per-project lock is taken. Without per-phase tracing, an
indefinite stall on the lock looks identical to an indefinite stall
inside the build itself — both surface to the user as
"State: building" forever, with zero log lines telling them which
phase is stuck.

Emit a tracing::info before lock.lock().await, a tracing::warn at 10s
if the lock is still being awaited, and a tracing::info on acquire
with the actual wait time. With #348 now flushing daemon tracing to
daemon.log, future hangs will localize within ~10s instead of being
invisible.

The 10s warn-threshold is well above normal lock contention (which
should be sub-millisecond when no other build is running) but below
the human-perceptible "is it hung?" window. After the warn fires
the code continues to await the lock — this is observability, not a
timeout, since silently dropping the lock and racing the holder
would corrupt build outputs.

Refs #346

Author: zackees

crates/fbuild-daemon/src/handlers/operations/build.rs

@@ -143,10 +143,46 @@ pub async fn build(
                 fbuild_core::DaemonState::Building,
                 Some(format!("Building {}", project_dir_desc)),
             );
+            // Daemon state goes to `Building` *before* the lock is taken
+            // (the OperationGuard above). Without per-phase tracing, an
+            // indefinite stall here looks identical to an indefinite
+            // stall inside the build itself — both surface as
+            // "State: building" forever. Emit a tracing event around the
+            // lock acquire so daemon.log shows when the daemon is queued
+            // behind another build vs. actually compiling. See #346
+            // finding (2). The 10s warn-threshold is well above normal
+            // contention but below any human-perceptible "is it hung?"
+            // window, so a stuck lock surfaces in the log within seconds
+            // instead of being invisible.
             let lock_wait_start = std::time::Instant::now();
             let lock = ctx.project_lock(&project_dir);
-            let _lock_guard = lock.lock().await;
+            tracing::info!("waiting for project lock on {}", project_dir_desc);
+            const LOCK_WAIT_WARN: std::time::Duration = std::time::Duration::from_secs(10);
+            let _lock_guard = {
+                let acquire = lock.lock();
+                match tokio::time::timeout(LOCK_WAIT_WARN, acquire).await {
+                    Ok(guard) => guard,
+                    Err(_) => {
+                        tracing::warn!(
+                            "project lock on {} not acquired within {}s — \
+                             another build is still holding it. Continuing \
+                             to wait; if this persists the daemon may be \
+                             stuck. Inspect ~/.fbuild/<env>/daemon/daemon.log \
+                             or run `fbuild daemon locks` to see who is \
+                             holding the lock.",
+                            project_dir_desc,
+                            LOCK_WAIT_WARN.as_secs(),
+                        );
+                        lock.lock().await
+                    }
+                }
+            };
             let lock_wait = lock_wait_start.elapsed();
+            tracing::info!(
+                "project lock acquired on {} after {} ms",
+                project_dir_desc,
+                lock_wait.as_millis()
+            );
 
             // Bridge: sync log lines → async NDJSON chunks
             let bridge_tx = async_tx.clone();