Task cache: no way to exclude a specific env var from env-enumeration fingerprints — inherited OLDPWD thrashes warm hits

## Summary

When a task's config chain enumerates the environment, cooperative tracking records the enumerated env vars into the task-cache fingerprint — including shell bookkeeping like `OLDPWD` that has no build meaning. `OLDPWD` changes with whichever directory the shell `cd`-ed into the repo from, so an otherwise-identical `vp run build` warm hit thrashes across shells and entry paths.

## Repro sketch

Laravel app built through `laravel-vite-plugin` (its config chain reads `.env` and enumerates `process.env`), driven by `vp run build`:

1. `vp run --filter ./apps-web/ build` twice — the second run is a full cache hit.
2. Re-enter the repo from a different parent directory (so the shell exports a different `OLDPWD`) and run the same command — cache miss, with the env fingerprint as the only change.

Observed on vite-plus 0.2.2 and unchanged as of 0.2.7 (our pinned version). The v0.2.8 release notes list no related change.

## What we tried

We could not find a vp-side config that excludes a specific env var from an enumeration-sourced record: `untrackedEnv` and negated `env` patterns (`env: ['!OLDPWD']`) did not suppress it in our testing (investigated during the same caching work as #1894 / #1774).

## Workaround

Our monorepo CLI bootstrap does `delete process.env.OLDPWD` before spawning any `vp` subprocess. It works, but it only protects invocations that go through the wrapper — plain `vp` calls still thrash.

## Ask

A first-class way to exclude named env vars from cooperative-tracking fingerprints, the way `input` globs filter file inputs — e.g. `untrackedEnv: ['OLDPWD']` (or `env: ['!OLDPWD']`) applying to enumeration-sourced records, not just direct reads. A reasonable complement would be default-excluding well-known shell bookkeeping vars (`OLDPWD`, `_`, `SHLVL`) that can never carry build meaning.