[folbricht]

Fixes #408.

A store that fails returns a nil chunk alongside its error. DedupQueue.GetChunk publishes that result to every caller waiting on the same in-flight request, where it arrives as a *Chunk held in an any. A typed nil in an interface is not an untyped nil, so the case nil arm never matched it — case *Chunk did, with a nil b, and clone() dereferenced it:

github.com/folbricht/desync.(*Chunk).clone(...)
	chunk.go:32
github.com/folbricht/desync.(*DedupQueue).GetChunk(...)
	dedupqueue.go:42

The first requester already guarded this a few lines below; only the waiters were missing it. WriteDedupQueue.GetChunk carried a second copy of the same switch, so both waiter paths now share one helper and can't drift apart again. The case nil arm went with it: markDone is only ever handed a *Chunk, so it was unreachable, and its presence is what made the switch look like it covered the nil case.

Two ways to reach it:

• untar -c <cache> on Windows, where cmd/desync/store.go wraps local stores in a WriteDedupQueue. Every cache miss on a fresh cache returns nil plus ChunkMissing, so any two goroutines asking for the same chunk at once can hit it.
• chunk-server on any platform, where cmd/desync/chunkserver.go wraps the store unconditionally. There an upstream failure took down the server process.

Present since clone() was introduced in #372, so v1.0.4, v1.1.0 and v1.1.1 are all affected.

The regression test panics on master and passes here. It uses synctest like TestDedupQueueParallel, so the waiters are guaranteed to have piled onto the request before it completes rather than relying on a sleep.