fix(kubeconform): a valid resource can fail validation with EOF

> 🤖 Generated by the Agentic Engineer

## Evidence

`TestValidateBytes_NamesFailingResource` failed once in CI on an unrelated PR (the diff touched only
`pkg/cli/clusterapi/*`, no overlap with this package):

```
--- FAIL: TestValidateBytes_NamesFailingResource (0.01s)
client_test.go:362: expected error not to implicate the valid Namespace, got:
validation failed: Namespace/test-namespace: EOF;
ConfigMap/demo/broken-config: problem validating schema ...
```

The **`ConfigMap` half is the intended failure**. The defect is the other half: `Namespace/test-namespace`
is valid and should not appear at all, and the reason it does is **`EOF`** — a stream-reading outcome,
not a schema verdict. The test's own assertion names exactly this ("expected error not to implicate the
valid Namespace").

Reproduction attempts: **8/8 PASS locally** (`-count=1`, same commit). So it is timing-dependent rather
than a deterministic regression.

One correlate from the failing run worth recording: the schema cache **missed**
(`Cache not found for input keys: kubeconform-schema-cache-v1-test-…`), so every schema was fetched
over the network on that run. That changes read timing for the resource stream, which is consistent
with a stream being consumed or aliased before it is fully read.

## Impact

A false failure on a valid resource, on a shared validation path. It is rare — 0 failures in the
previous 25 CI runs — but it fails a PR that has nothing to do with this package, and the failure mode
(a *valid* resource reported invalid) is the kind that erodes trust in the check. It is also the shape
that could mask a real validation result.

Note this repository's own tooling has hit a related upstream problem before: a buffer-aliasing data
race in kubeconform's `resource.FromStream` is already documented as a source of non-determinism in the
platform's validate step.

## Acceptance criteria

- [ ] Root-cause why a valid resource can yield `EOF` — establish whether the resource stream is read
concurrently, reused, or consumed twice.
- [ ] A regression test that fails deterministically for that cause (stress/`-race`/`-count=N`, or a
seam that forces the interleaving) rather than relying on chance.
- [ ] The fix is at the root cause — not a retry, a skip, or a widened assertion.
- [ ] Confirm whether the schema-cache miss is causal or merely correlated, and record which.

Start with TestValidateBytes_NamesFailingResource in client_test.go and trace the shared validation path into kubeconform's resource.FromStream handling. Use repeated runs, -race, or a controlled seam to establish whether the stream is consumed, reused, or read concurrently, then compare behavior with and without the schema-cache miss. Done means a deterministic regression test, a root-cause fix, and a recorded conclusion about cache causality.

Written by the indexing model from the issue text.