`docker context export` writes a truncated tar archive

Start with Export() in cli/context/store/store.go and inspect how the tar writer and output writer are closed. Run the existing tests in cli/context/store, then verify an exported context with TLS files is a complete tar archive accepted by Python tarfile and macOS tar.

Description

docker context export writes a truncated tar file. The two zero blocks that end a tar archive are never written, and when the context has TLS files, the padding after the last file is missing too.

docker context import still reads these files, because Go's archive/tar stops quietly at EOF. Other readers are stricter: with TLS files in the context, Python's tarfile rejects the export, and so does the macOS tar when reading it from a pipe (output below).

The cause is the order of these deferred calls in Export() in cli/context/store/store.go:

tw := tar.NewWriter(writer)
defer tw.Close()
defer writer.Close()

Deferred calls run last-in, first-out. So the pipe is closed first, and when tw.Close() then tries to write the padding and the trailer, it gets io.ErrClosedPipe. That error is ignored. The code hasn't changed since the context store was added in b34f340346f (2018).

Reproduce

$ openssl req -x509 -newkey rsa:2048 -nodes -keyout /dev/null -out ca.pem -days 1 -subj "/CN=example"
$ docker context create example --docker "host=tcp://127.0.0.1:2376,ca=$PWD/ca.pem"
example
Successfully created context "example"
$ docker context export example example.tar
Written file "example.tar"
$ wc -c < example.tar
3667

A tar file is always a multiple of 512 bytes, and 3667 isn't (the exact size depends on the certificate). The file stops 83 bytes into a block, right after the contents of tls/docker/ca.pem:

$ python3 -m tarfile -l example.tar
Traceback (most recent call last):
  ...
ReadError: unexpected end of data

$ docker context export example - | tar -tf - > /dev/null
tar: Truncated input file (needed 1536 bytes, only 1107 available)
tar: Error exit delayed from previous errors.

Expected behavior

A complete tar file: each file padded to a 512-byte boundary, then the end-of-archive marker. Other tar tools should be able to read the export too.

docker version

Client:
 Version:           29.8.0
 API version:       1.56
 Go version:        go1.26.8
 Git commit:        88096ef
 Built:             Thu Sep  3 21:49:43 2026
 OS/Arch:           darwin/amd64
 Context:           default

Server: Docker Desktop 4.91.0 (239619)
 Engine:
  Version:          29.8.0
  API version:      1.56 (minimum version 1.40)
  Go version:       go1.26.8
  Git commit:       3ce5872
  Built:            Thu Sep  3 21:51:20 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.3.4
  GitCommit:        db8809540e1a7a9da5d518876894933ff55692ab
 runc:
  Version:          1.4.3
  GitCommit:        v1.4.3-0-gbb14dabe
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

N/A, the daemon isn't involved. This happens in the CLI's context store (cli/context/store).

Additional Info

Same result with the CLI built from master (7fc2dff9bc).

Without TLS files the archive happens to end on a block boundary, and the readers above accept it. The end-of-archive marker is still missing, though.

Closing the tar writer before the pipe fixes it. With this change, the export from the steps above is a complete archive that both readers accept, and the existing tests in cli/context/store still pass:

tw := tar.NewWriter(writer)
defer func() {
	// Close the tar writer first, so that the padding and the
	// end-of-archive marker are written before the pipe is closed.
	writer.CloseWithError(tw.Close())
}()

Happy to open a PR for this.