turborepo

a38658aa - fix: Validate engine concurrency after task-level filtering (#12540)

fix: Validate engine concurrency after task-level filtering (#12540) ## Summary - Fixes a bug where enabling the `filterUsingTasks` future flag causes a spurious persistent task concurrency error (e.g. "You have 65 persistent tasks but `turbo` is configured for concurrency of 10") - The persistent task count was being validated against the **full pre-filter engine** (all packages) instead of the **post-filter engine** (only the tasks that will actually execute) ## Root Cause When `filterUsingTasks` is active, the engine is intentionally built with all workspace packages so that the task-level filter has the complete graph to resolve against. However, `engine.validate()` was called inside `build_engine()` — **before** `filter_engine_to_tasks()` pruned the graph in the calling `build()` method. For `turbo --filter vercel-site dev`, validation saw 65 persistent tasks (34 `dev` + 31 `dev:ts` across the entire workspace) instead of the 3 that survive filtering (`vercel-site#dev`, `vercel-site#dev:ts`, `vercel-site#proxy`). ## Fix Moves `engine.validate()` from `build_engine()` to `build()`, after all task-level filtering (`filterUsingTasks` and `affectedUsingTaskInputs`) is complete. ## Testing Existing `persistent_dependencies` integration tests (15 tests) and engine validation unit tests all pass. Verified manually on a large monorepo where the bug was originally observed.