test(v4): pin the check-chain case that keeps compiled validate's definite guard (#6551)

#6544 gave the interpreted parse the same first-failure exit that generated code has always had, which makes it look like the `definite` guard added in #6538 is now redundant: if both settle on the first failure, a compiled `INVALID` and an interpreted `false` agree, and `z.validate` could take the fast path for any schema carrying a `.refine()`.

It is not redundant, and the reason is the check chain rather than the sibling walk. A continuable issue does not settle the interpreter's walk, so it runs the rest of the chain:

```ts
z.validate(z.string().min(5).refine(boom), "ab"); // throws: .min() is continuable, so the refine still runs
```

Generated code returns `INVALID` at the failed `.min()` and never reaches the refine. Drop the guard and that pair diverges — compiled answers `false` where the interpreter throws. Measured with the guard removed: 6 divergences across `.refine()`, `.superRefine()`, `z.custom()`, string and number ranges, and `z.email()`; with it restored, zero.

Two rows in the parity fuzz now cover it. Both branches of the refine generator already throw on a thenable, so nothing else in that generator would have caught this.

The failure-model paragraph in `wiki/compile.md` named the sibling case as the reason. That premise is stale after #6544, so it now names the check chain and says outright that the sibling case alone would no longer justify the flag.