image: deflake TestCopyCtx_MidStreamCancel

[deveshctl]

What

Fix the intermittent failure of TestCopyCtx_MidStreamCancel that surfaced on main after #39 and #40 merged in sequence.

Why

The test's blockingReader returned io.EOF on its second Read once the test called close(br.release). But copyCtx returns nil on EOF (line 26-27 of image/copyctx.go) before its next top-of-loop ctx.Err() check. So this scheduling order produced the failure:

1. Copy goroutine writes the first chunk.
2. Copy goroutine loops, passes ctx.Err() (still nil), enters second src.Read.
3. Test sees dst.Len() == len(first), calls cancel(), then close(br.release).
4. Reader returns (0, io.EOF).
5. copyCtx sees rerr == io.EOF → returns (written, nil).

Result: error = <nil>, want context.Canceled. Both #39 and #40's PR runs passed in isolation; the failure only showed on main's run for #40 because of CI scheduling.

Fix

Test-only. Give blockingReader a context, and have its second Read block on <-ctx.Done() then return ctx.Err() instead of io.EOF. Now whichever side observes the cancel first yields context.Canceled to copyCtx:

• copyCtx's top-of-loop ctx.Err() returns it directly, or
• the reader's <-ctx.Done() unblocks and returns ctx.Err(), which copyCtx propagates via the rerr branch (line 29-30).

Either way, cerr == context.Canceled deterministically. No change to production copyCtx.

Verification

• go build ./... and go vet ./... clean locally (Windows dev-machine constraint precludes go test).
• CI build-and-test job will verify on Linux.