Validate chunk size in IndexPos read path to prevent panic/hang

[folbricht]

Problem

IndexPos (used by desync cat and the desync mount-index FUSE read handler) assumes the invariant len(curChunk) == Index.Chunks[curChunkIdx].Size, but nothing enforced it:

• findOffset bounds curChunkOffset against the declared size from the index, not the actual chunk data.
• loadChunk stored the chunk bytes from the store without comparing their length to the declared size.
• The index parser only rejects Size > ChunkSizeMax, so a declared size like 1000 against a real 4‑byte chunk (default max 256 KiB) passes validation.

A .caibx that references a real chunk ID present in the store but over-declares that chunk's Size therefore triggers:

• Panic — Seek(200) sets curChunkOffset = 200 (within the declared 1000), then Read loads the real 4‑byte chunk and evaluates curChunk[200:4] → slice bounds out of range at readseeker.go:148. With mount-index this crashes the daemon and orphans the mount.
• Infinite loop — when the offset reaches the real end of a non-last chunk but is still below the declared size, Read copies 0 bytes and Seek(0, SeekCurrent) makes no progress, hanging the caller forever.

Fix

After loading a chunk, verify its actual length matches the size the index declares for it and return an error on mismatch — the same check AssembleFile already performs (assemble.go:73). The null-chunk shortcut path is covered too (a legitimate null chunk always declares Size == ChunkSizeMax). This restores the invariant the rest of the read path relies on, eliminating both the panic and the hang; callers receive an "unexpected size for chunk" error through the normal io.Reader path instead.

Tests

Added readseeker_test.go:

• TestIndexReadSeekerSizeMismatchPanic — over-declared chunk + seek/read returns an error instead of panicking.
• TestIndexReadSeekerSizeMismatchNoLoop — short non-last chunk returns an error promptly instead of spinning (goroutine + 5s timeout guard).
• TestIndexReadSeekerValid — a well-formed multi-chunk index (including a memory-served null chunk) still reads back correctly, with and without seeking.

Reverting the fix makes the first test panic at readseeker.go:148 and the second time out; the valid-path test passes either way. Full library suite and cmd/desync build pass.