Fix CPU starvation warning in MillBuildTool classpath extraction

[rochala]

Summary

• Wrap parseClassesDir (calls Files.isDirectory) in IO.blocking — was running as a pure assignment on the compute pool
• Wrap ClasspathOutputParser.parseJsonArray call (iterates Files.exists over all classpath entries) in IO.blocking — was pattern-matched directly on the compute pool

These blocking file-system checks on the compute thread pool triggered the cats-effect CPU starvation warning:

Your app's responsiveness to a new asynchronous event was in excess of 100 milliseconds. Your CPU is probably starving.

Test plan

• ./mill lib.compile passes
• get --module lib cellar.build.MillBuildTool returns results without warning
• search --module lib ProcessRunner and list --module lib cellar.build work cleanly
• get-external org.typelevel:cats-effect_3:3.5.4 cats.effect.IO works

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adjusts execution context usage to avoid cats-effect CPU starvation warnings by moving file-system–backed classpath extraction work off the compute pool.

Changes:

• Wrap parseClassesDir (includes Files.isDirectory) in IO.blocking during Mill classpath extraction.
• Wrap ClasspathOutputParser.parseJsonArray (includes Files.exists checks) in IO.blocking.
• Change symbol-stream filtering to use evalFilter with IO.blocking(PublicApiFilter.isPublic).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
lib/src/cellar/build/MillBuildTool.scala	Moves blocking filesystem checks involved in classpath extraction onto the blocking pool.
lib/src/cellar/SymbolLister.scala	Switches public filtering to effectful evalFilter with IO.blocking.
lib/src/cellar/AllSymbolsStream.scala	Switches public filtering to effectful evalFilter with IO.blocking.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

PublicApiFilter.isPublic is a pure, in-memory predicate (see lib/src/cellar/PublicApiFilter.scala) and does not perform blocking I/O. Wrapping it in IO.blocking and switching from .filter to .evalFilter introduces an effect + blocking-pool shift per symbol, which can significantly hurt throughput when listing many symbols. Prefer keeping .filter(PublicApiFilter.isPublic) (or, if an effect is truly needed, use evalFilter(sym => IO(PublicApiFilter.isPublic(sym))) without blocking).

[Copilot]

Same concern here: PublicApiFilter.isPublic is not blocking, so IO.blocking + evalFilter adds unnecessary overhead and shifts every element to the blocking pool. Consider reverting to .filter(PublicApiFilter.isPublic) (or evalFilter(sym => IO(...)) without blocking if you need an effect for composition).

[Copilot]

This change moves public-symbol filtering onto IO.blocking, but PublicApiFilter.isPublic is a pure predicate (no file-system calls). Besides the per-element context shift overhead, this is also a discrepancy with the PR title/description which focus on Mill classpath extraction; either document why symbol filtering needed this change (and how it addresses CPU-starvation warnings), or split/revert this part to keep the PR scoped.