[import] pre-opened stat readers can leak on iterator initialization failure or early close

Bug Report

1. Minimal reproduce step (Required)

This issue was found by AI-assisted static analysis while reviewing #70942. It covers two ownership failures in the asynchronous stat-reader pre-open pipeline used by newMergePropBaseIter.

Initialization-error path

1. Build a MultipleFilesStat with more than 2 * limit stat files so newMergePropBaseIter starts asynchronous pre-opens and can fill preOpenCh.
2. Make one of the first limit synchronous NewStatsReader calls fail while asynchronous opens for later files succeed.
3. newLimitSizeMergeIter returns an error, and newMergePropBaseIter returns a half-built iterator together with that error.
4. NewMergePropIter discards the iterator without closing closeCh. The producer can remain blocked on preOpenCh, and successfully pre-opened readers have no remaining owner.

Early-close path after the producer exits

1. Build a MultipleFilesStat with len(Filenames) <= 2 * limit and make every stat-reader open succeed.
2. Wait until the producer has put all asynchronous task channels into preOpenCh and exited, without consuming those tasks through the iterator.
3. Call mergePropBaseIter.close().
4. close() waits for the finished producer and closes readers owned by m.iter, but it never drains the successful readers still buffered behind preOpenCh.

Relevant review findings:

• https://github.com/pingcap/tidb/pull/70942#discussion_r3957158973
• https://github.com/pingcap/tidb/pull/70942#discussion_r3957158982

The relevant producer, constructor return, and close logic predates #70942 and was introduced by #49832.

2. What did you expect to see? (Required)

Reader ownership should be resolved on every constructor and shutdown path. If iterator construction fails or the iterator closes before consuming all pre-opened tasks, all producer goroutines should terminate and every successfully opened StatsReader should be closed exactly once.

3. What did you see instead (Required)

On an initialization error, the half-built iterator is discarded without signaling closeCh. Depending on the number of files, the producer either blocks indefinitely after filling preOpenCh or exits while successful reader results remain unconsumed. In both cases, pre-opened readers can leak.

On early close after the producer has already exited, the only preOpenCh drain is no longer reachable. mergePropBaseIter.close() does not drain the remaining tasks, so their readers stay open together with their storage connections and prefetch buffers.

4. What is your TiDB version? (Required)

Confirmed by source inspection on PR #70942's base commit 10f06594e7e60c2238a951d9bc151132b6f5f0c0. The ownership structure traces back to commit 8a79c0d56c6f7f9570ba6d4697ace1f26ce46b45 from December 2023.

Not dynamically reproduced against a released TiDB version or real S3/GCS service yet.

Suggested fix

• Make newMergePropBaseIter self-cleaning when newLimitSizeMergeIter returns an error, and return nil, err rather than an unusable half-built iterator.
• Give close() unconditional ownership of draining any task channels left in preOpenCh after the producer stops, while ensuring a reader is closed exactly once.
• Consider ctx.Done() as an additional producer exit signal, but do not rely on cancellation alone to release readers that were already opened.
• Add deterministic tests that track open-reader references for both an initialization failure with a full channel and an early close after successful pre-opens.

Parent issue

• #69798