cli/context/store: limit decompressed size of TLS files on zip import

[UditDewan]

- What I did

Fixed a memory exhaustion issue in docker context import with zip archives (fixes #6917).

The meta.json entry of an imported zip archive is read through limitedReader (10MB cap), but tls/ entries were read with a bare io.ReadAll. Only the compressed archive size was capped, so a small crafted zip containing a highly compressible TLS entry could decompress to gigabytes and OOM the CLI.

- How I did it

• Read TLS entries in importZip through the same limitedReader already used for meta.json.
• Removed the l.N == 0 early-EOF branch from limitedReader.Read. Without this, content exceeding the limit was silently truncated (instead of rejected) whenever a read landed exactly on the remaining budget — which is deterministic for zip imports, since flate delivers 32KiB chunks that divide the 10MB cap evenly. True end-of-data still returns a clean io.EOF via the underlying reader.

- How to verify it

go test ./cli/context/store/

New regression tests:

• TestImportZipTLSDataTooLarge — imports a zip whose TLS entry inflates past the cap while the archive itself stays well under it, and asserts the import errors.
• an added TestLimitReaderReadAll case using iotest.OneByteReader that lands a read exactly on the limit with data remaining, and asserts the limit error is returned.

- Human readable description for the release notes

Fix `docker context import` allocating unbounded memory for TLS files contained in zip archives