Make PermanentStore.Stop wait for in-flight blocks, not just queue drain

[damilolaedwards]

Summary

• Stop's readiness check watched the queue channel's length, which drops to zero the moment a worker receives a block off the channel, not when it actually finishes processing it. A caller that tore things down (closed the DB pool, exited the process) right after Stop returned could interrupt a block still mid-copy or mid-database-write.
• Tracks outstanding work with a sync.WaitGroup instead: QueueBlock reserves a slot before a block is admitted to the queue, and the worker releases it only after that block is fully handled, success or failure. Stop now blocks on the WaitGroup rather than queue length, still bounded by the caller's context.
• A mutex guards the stopped flag against the WaitGroup's Add/Wait sequence, so a QueueBlock call can't race Stop into calling Add after Wait has already returned.

Test plan

• go build ./... and go vet ./...
• New tests: Stop waits for a real in-flight Copy to finish before returning (verified against a delayed store wrapper), Stop still returns promptly when idle, Stop respects context cancellation, QueueBlock after Stop doesn't panic the WaitGroup
• All new tests pass under -race across repeated runs
• Confirmed the new tests fail against the pre-fix code (queue-length-based Stop returns immediately instead of waiting)
• Full repo test suite not run locally: some existing test files in this package depend on Docker/testcontainers, unavailable in this environment