Fix flaky TestCatFileBatch/QueryTerminated test

[silverwind]

TestCatFileBatch/QueryTerminated relied on timing to distinguish os.ErrClosed vs io.EOF error paths. Replace time.Sleep-based synchronization with a channel-based hook on pipe close, making both error paths fully deterministic regardless of CI runner speed.

Ref: https://github.com/go-gitea/gitea/actions/runs/24193070536/job/70615366804

---

This PR was written with the help of Claude Opus 4.6

[Copilot]

Pull request overview

This PR reduces flakiness in TestCatFileBatch/QueryTerminated by widening timing margins in a race-sensitive test so CI scheduling variance is less likely to flip the observed error (os.ErrClosed vs io.EOF).

Changes:

• Increased the “reader slower than close” delay to more reliably produce os.ErrClosed.
• Increased the “close slower than reader” delay to more reliably produce io.EOF.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gerliczkowalczuk]

@silverwind This change makes sense to me, especially the idea of controlling the race between Read and pipe closing in tests.

I just have a question about the implementation:

• Regarding the global debug hook:

  var catFileBatchDebugPipeClose atomic.Pointer[func(stdPipeClose func())]

  This is used from tests to control timing, which is really helpful, but is there any concern about this being global state if tests run in parallel?

  I see defer ...Store(nil) is used, but I’m wondering if this would still be safe if t.Parallel() is ever introduced in this package, since tests could override this pointer concurrently.

• Also, just to confirm my understanding of the two test cases:

  • PipeClosedBeforeRead → os.ErrClosed
  • ReadBeforePipeClose → io.EOF

  The difference here is purely the ordering enforced by the hook and channels, right?

Overall, replacing the previous timing-based approach with hooks + channels makes the test much clearer and more deterministic. Nice improvement!

[silverwind]

Above comment seems like AI spam, but I still checked it and there's nothing addressable in it.