DiskFileSystem: store Effect full_path as Arc<Path> (#94332)
### What?
In the `DiskFileSystem` `write` and `write_link` implementations
(`turbopack/crates/turbo-tasks-fs/src/lib.rs`), change the `full_path`
field on the `WriteEffect` and `WriteLinkEffect` structs from
`Arc<PathBuf>` to `Arc<Path>`.
### Why?
`Arc<PathBuf>` stores two heap allocations and an extra indirection: the
`Arc` allocation holds a `PathBuf` (`Vec<u8>`-like), which in turn
points to the actual path bytes. `Arc<Path>` is a thin/wide-pointer to a
single allocation containing the path bytes inline next to the `Arc`
header, which is both smaller (no separate `PathBuf` capacity field) and
removes one level of pointer chasing on every access.
These effects are cloned per write side-effect and live until the effect
is applied, so the saved allocation/indirection is a small but free win.
### How?
- Change the `full_path` field type on `WriteEffect` and
`WriteLinkEffect` from `Arc<PathBuf>` to `Arc<Path>`.
- Update the two construction sites from `Arc::new(full_path)` to
`Arc::from(full_path)`, which uses the standard library's `From<PathBuf>
for Arc<Path>` impl to move the path bytes directly into a single
`Arc<Path>` allocation.
No call sites needed updating: all existing uses
(`validate_path_length(&self.full_path)`,
`self.inner.invalidate_from_write(&self.full_path)`,
`self.full_path.as_os_str()`) already only need `&Path`, which is
reached via `Deref` from both `Arc<PathBuf>` and `Arc<Path>`.
Verified locally with `cargo check -p turbo-tasks-fs` and `cargo clippy
-p turbo-tasks-fs --all-targets`.
<!-- NEXT_JS_LLM_PR -->
Co-authored-by: v-work-app[bot] <262237222+v-work-app[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com>
