fix(csi): refuse to reformat a restore whose device reads blank

[onedr0p]

A restored volume whose device comes up blank is silently mkfs'd instead of refused, so the consumer mounts an empty filesystem and the restore reads as successful. This closes the silent half; the underlying "why was the device blank" is still open (see below).

What CI showed

Both merge-queue runs of #364 failed Go E2E (replicated) on restore data-consistency specs. kubelet derives the staging directory from sha256(volume handle), which lets the ginkgo timeline be correlated to the agent logs. For volumegroupsnapshottable-2633 in run 30474605146:

PVC	volume	staged
restored-…-0	pvc-9d27148c… (sha256 ca643272…)	mkfs ext4 on /dev/drbd1008 @ 17:38:51
restored-…-1	pvc-a141f9e3… (sha256 a0eac492…)	mkfs ext4 on /dev/drbd1006 @ 17:38:51
restored-…-2	pvc-a2b31493…	no mkfs, data intact

The two the test flagged were reformatted at NodeStage. Their sources were mkfs'd at 17:38:15/17:38:19 and the group snapshot was cut at 17:38:31, so MiroirSnapshot.Status.SourceFormatted should have been true and CreateVolume should have stamped the clones Formatted — which would have tripped the existing codes.DataLoss refusal in stage.EnsureFilesystem instead of formatting.

Why the refusal did not fire

The refusal reads vol.Status.Formatted from whatever stage.Device loaded, and the node service is built on the manager's cached client (csi.NewNode(mgr.GetClient(), …)). The controller stamps a clone's inherited flag through the APIReader immediately after Create (controller.go:1900), and the restore is staged seconds later — comfortably inside the window where the node's informer cache can still carry the volume as never-formatted. The guard then reads false and mkfs proceeds.

The change

stage.Deps gains an uncached Reader (same convention as SnapshotReconciler.Reader and Controller.APIReader, falling back to the cached client when unset). When a device reads blank on a volume with Spec.Source != nil, the "never formatted" answer is confirmed against the API server before mkfs; a confirmation that cannot be read is Unavailable, so kubelet retries instead of formatting on a guess.

• Fresh volumes are untouched: no content source, no extra read, first-stage mkfs as before.
• A restore of a genuinely unformatted source still formats — the live flag says so.
• The gateway needs no wiring; its client is already uncached.

What this does not fix

Why the leg was blank while DRBD reported it UpToDate. Ruled out by reading: birthInitPending excludes every Spec.Source != nil volume, the group cut does be.Sync and gates on local + peer UpToDate, publishMembers does set SourceFormatted, snapshot LV names are not truncated so members cannot collide, and a missing snapshot LV fails loudly in CreateFromSnapshot. Pinning it needs the volume CR, drbdsetup status and agent logs from the moment of staging; diagnostics.sh runs at suite end, after the namespace is gone, and the agents log nothing at info level on the restore path. Worth a follow-up that dumps per-spec state on failure.

After this change that failure mode surfaces as a DataLoss stage refusal — a stuck pod with a named cause — instead of a pod that comes up holding an empty filesystem.

Verified

go build ./..., go vet ./..., the unit suite, test-integration (27 specs, envtest) and golangci-lint run all pass. New unit tests cover the stale-cache refusal, the unformatted-source restore that must still format, the fresh-volume path taking no extra read, and the read failure surfacing Unavailable.