vp run: cache key encoding failure skips all tasks and exits 0 ("0/0 cache hit")

### Summary

When `vp run` fails to encode a task's cache key, it prints the failure to **stdout**, then runs **zero tasks** and exits **0**.

```console
$ vp run codegen
✗ Cache lookup failed: Encoded sequence length exceeded preallocation limit of 4194304 bytes (needed 9831192 bytes)
---
vp run: 0/0 cache hit (0%). (Run `vp run --last-details` for full details)

$ echo $?
0
```

The task never executed, nothing was generated, and the exit status says everything is fine.

### Impact

This reached us through a CI check that regenerates a committed artifact and diffs it. The check ran `vp run `, got exit 0, compared the file against itself, and reported "up to date" — while codegen had not run at all. The check had been structurally incapable of noticing.

In CI (Linux) the same invocation exited with status **135** instead of 0, with no output at all, which is a second inconsistency: the same condition produces a silent success locally and an unexplained non-zero status in CI.

### Expected

A cache-layer failure should never be able to skip work. Either fall back to running the task uncached, or fail loudly with a non-zero exit. `0/0` tasks executed with exit 0 should not be reachable when a task was requested.

Two smaller points:

- The diagnostic goes to stdout, so it disappears for any caller using `stdio: ["ignore", "ignore", "inherit"]` — which is a natural choice for a wrapper that only cares about stderr. It belongs on stderr.
- 4 MiB looks like a fixed preallocation rather than a limit that should be enforced; growing past it is a normal thing for a large workspace to do.

### Reproduction

I do not have a minimal reproduction — the encoded size depends on workspace scale. Ours crossed the threshold at roughly 1,300 first-party source files after an import-graph change; the task itself is a single `graphql-codegen` invocation whose output is ~870 KB. Scaling a synthetic workspace to 80,000 trivial modules did not reach the limit, so the encoded sequence appears to be driven by something other than raw input file count.

Happy to gather more detail if there is a debug flag that dumps what goes into the cache key.

### Environment

- `vp` 0.1.24
- Local: macOS 15 (Darwin 25.4.0), arm64, Node 26.8.1 → exit 0, `0/0`
- CI: Linux x86_64, Node 26.8.1 → exit 135, no output

Possibly related to #2635 (cache layer degrading to a silent success).

Inizia dal percorso di ricerca della cache di `vp run` e, se possibile, riproduci su macOS e Linux il fallimento segnalato di `vp run codegen`. Traccia come vengono segnalati gli errori di codifica della chiave della cache e come vengono determinati l’esecuzione dell’attività e lo stato di uscita. Il lavoro è completato quando un errore della cache non può produrre un successo silenzioso `0/0`: l’attività viene eseguita senza cache oppure il comando termina con uno stato diverso da zero, con diagnostica su stderr.

Scritto dal modello di indicizzazione a partire dal testo della issue.