Right now, pulls of encrypted layers try to decrypt and extract them without handing encrypted data specially, so, we see something including invalid tar header (or, with future containers/image#2613, writing blob: layer 0 (blob "sha256:…"/""/"sha256:…") does not match config's DiffID "sha256:…").

That’s valuable for tests because we can ensure that the data really is encrypted, but bad for users.

We should add a “requires decrypted layers” field to private.ImageDestination, and abort a copy before starting to read any layers if isEncrypted and the transport requires decryption.