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).

Start with the `vp run` cache lookup path and reproduce the reported `vp run codegen` failure on macOS and Linux if possible. Trace how cache-key encoding errors are reported and how task execution and exit status are decided. Done means a cache failure cannot produce silent `0/0` success: the task runs uncached or the command exits non-zero, with diagnostics on stderr.

Written by the indexing model from the issue text.