turbo

623aadc0 - perf: Stop materializing spans for the disabled daemon log layer (#13244)

perf: Stop materializing spans for the disabled daemon log layer (#13244) ## Why The daemon file logger's `EnvFilter` (INFO and up) wrapped the *outside* of its reload layer, so it declared interest in INFO-level callsites for the entire process lifetime — even though the inner layer is `None` in every non-daemon process. The registry materialized every INFO-level span (slab insert, enter/exit bookkeeping, close) with no consumer. On a synthetic 1500-package monorepo with a fully cached `turbo run build`, this overhead is 4.2–5.7% of total CPU (perf, flat self-time across `tracing_subscriber`/`tracing_core` symbols). ## What The daemon log filter is now itself a `reload` layer that starts as `off` and is swapped to the real INFO filter when `set_daemon_logger` is called (i.e. only in the daemon process). While off, the layer declares no callsite interest, so unconsumed spans are never created. The filter is swapped rather than the whole `Filtered` wrapper because a `Filtered` only receives its `FilterId` when the subscriber stack is first built — swapping a newly built `Filtered` in via reload silently drops everything (verified empirically; the daemon's own log file came out empty). ## How to verify - Interleaved A/B, 15 pairs, 1500-task FULL TURBO runs: CPU 447→418ms and 366→339ms across two rounds (−6 to −7%); wall −4 to −5%. Under perf, tracing symbols drop from ~5% of samples to zero. - `--profile` chrome traces are unaffected: identical event counts (64865 events, 3000 `queue_task` begin/end) before and after, since enabling chrome tracing rebuilds the interest cache. - Daemon logging is unaffected: start/run/stop against the same repo writes the same log lines before and after. TTFT/dry-run paths see no change (span churn is execution-phase only; dry runs measured 0.5% tracing CPU on both).