Fixes #91653

Running `next dev` with the latest Turbopack fails to fetch fonts on
Windows ARM machines, resulting in an `http2 feature is not enabled`
error. This issue was fixed in `reqwest` v0.13.2:
seanmonstar/reqwest#2927

…(false) (#92631)

## Summary

- The notify `Config` uses a builder pattern where `with_follow_symlinks()` consumes `self` and returns a new `Config`, but the return value was being discarded — so `follow_symlinks` remained at its default (`true`).
- The `RecommendedWatcher` branch was also passing `Config::default()` instead of the configured `config` object, ignoring the config entirely.

## Test plan

- [x] `cargo check -p turbo-tasks-fs` passes
- Behavioral: symlinks under the watched root will now trigger events for the symlink itself rather than the target, matching the intent of the existing comment.

<!-- NEXT_JS_LLM_PR -->

…#92580)

### What?

Refactors the Safari `?ts=` cache-busting workaround in the Pages Router so it **only appears on CSS and font URLs**, not on script tags or script preload links.

### Why?

The `?ts=` timestamp was originally added to all preloaded assets as a workaround for a [Safari caching bug](https://bugs.webkit.org/show_bug.cgi?id=187726) (see [#5860](#5860)). When it appears on `<script>` tags, the Turbopack runtime's `getAssetSuffixFromScriptSrc()` reads the executing script's query string and infers it as the `ASSET_SUFFIX`, which then leaks onto all static asset URLs — including images. This causes `next/image` validation errors because the image URL gets an unexpected `?ts=` parameter.

Fixes #92118

### How?

Instead of maintaining parallel `assetQueryString` (with `?ts=`) and `scriptAssetQueryString` (without `?ts=`) paths, this PR:

1. **`assetQueryString`** carries only the deployment token (`?dpl=...`) and is used for all script-related URLs (script tags, script preloads)
2. **`safariCacheBuster`** is a new, separate field (`?ts=<timestamp>` or `""`) that is only combined with `assetQueryString` at the 3 CSS/font URL sites via a `joinQueryStrings()` helper
3. Removes the `scriptAssetQueryString` / `scriptMutableAssetQueryString` / `cssAssetQueryString` fields entirely

The Safari cache-buster is computed the same way as before (dev server only, Safari user-agent check) — it just no longer contaminates the base query string.

### Test plan

- [x] Updated existing test in `test/e2e/app-document/rendering.test.ts` to assert `?ts=` appears only on `<link rel="preload" as="style">` and `<link rel="preload" as="font">`, and does NOT appear on `<script>` or `<link rel="preload" as="script">`
- [x] `pnpm --filter=next types` passes

<!-- NEXT_JS_LLM_PR -->

…#92731)

Expand `config.compiler.define` to support number and boolean primitives
as well.

The support is already in Turbopack's rewrite engine, as well as
Webpack's DefinePlugin. We just need to modify the zod schema to
actually support passing numbers and bools.

Added an E2E test that should check all supported types.

… during recomputation (#92725)

### What?

Fix an infinite recomputation loop in turbo-tasks by allowing cell
cleanup to proceed during recomputation even when the task result is an
error.

### Why?

When a task errors during normal execution, cell cleanup is
intentionally skipped. The rationale is that errors during normal
execution are often transient eventual-consistency issues caused by
reading stale inputs — keeping old cell data prevents "cell no longer
exists" errors for dependent tasks that are reading those cells.

However, during **recomputation** (a task re-executing without being
marked dirty), nothing about its inputs has changed. Any error it
produces is therefore not transient. If cell cleanup is skipped in this
case, stale cells remain in place, which trigger further recomputations,
which produce further errors, which skip further cleanups — creating an
infinite loop.

### How?

- Detect whether a task execution is a recomputation by checking
`task.is_dirty().is_none()` at completion time (a recomputing task was
not dirty when it started executing).
- Propagate `is_recomputation` through
`TaskExecutionCompletePrepareResult` to both
`task_execution_completed_prepare` and
`task_execution_completed_cleanup`.
- In both places where cell cleanup is gated on `result.is_ok()` /
`!is_error`, extend the condition to also allow cleanup when
`is_recomputation` is true.

This ensures that stale cells produced by a erroring recomputation are
cleaned up, breaking the infinite loop.

<!-- NEXT_JS_LLM_PR -->

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…dex (#92828)

### What?

In `ModuleBatchesGraph::get_entry_index`, when an entry module is not
found in the graph, the error message included the full list of all
possible entries (with their resolved string identifiers). This is an
expensive operation that requires async resolution of every entry's
`ident().to_string()`.

### Why?

In production builds, this verbose error output is unnecessary overhead
and produces very long error messages that are hard to read. The list of
possible entries is only useful during development/debugging.

### How?

Gate the expensive "possible entries" diagnostic behind
`cfg!(debug_assertions)`. In release builds, a short `bail!("Entry is
not in graph")` is used instead. In debug builds, the full diagnostic
with all possible entry identifiers is still shown to aid debugging.

This mirrors the same approach already applied to
`ChunkGroupInfo::get_index_of`.

<!-- NEXT_JS_LLM_PR -->