[common] Release the BTree index file on every path that abandons the writer

[PDGGK]

Purpose

BTreeIndexWriter opens a PositionOutputStream in its constructor and, before this change, gave it back on exactly one path: the success path of finish(). Three ways that leaves the file open.

1. The writer is the only one its owners cannot release. It is the only GlobalIndexSingleColumnWriter in src/main that does not implement Closeable:

writer	Closeable
BitmapGlobalIndexWriter MultiValueBitmapIndexWriter FMGlobalIndexWriter NativeFullTextGlobalIndexWriter NativeVectorGlobalIndexWriter LuminaVectorGlobalIndexWriter ESIndexGlobalIndexWriter	yes
BTreeIndexWriter	no

Both cleanup paths a btree writer can reach guard on that:

// PkSortedIndexFile#build, in the finally block
if (writer instanceof AutoCloseable) {
    IOUtils.closeQuietly((AutoCloseable) writer);
}

// SortedSingleColumnIndexWriter#close, reached from SortedGlobalIndexWriter's
// try-with-resources and from the Flink SortedIndexBuildOperator
if (writer instanceof AutoCloseable) { ... }

For a btree writer both evaluate false, so the writer is skipped without a word. A build abandoned before finish() — the row source fails, or a Flink or Spark CREATE GLOBAL INDEX ... btree task is cancelled — leaves the stream open with nothing left that can reach it: the class exposes neither a close() nor any accessor for out. On the PkSortedIndexFile path, deleteCreatedFiles() then unlinks the target while that stream is still open.

2. A partially built writer keeps the file. The constructor opens the stream, then builds the comparator and the SstFileWriter. If either throws, the stream is already open and the object is never handed back.

3. finish() keeps the file when it fails. It writes the null bitmap, the bloom filter, the index block and the footer before closing. Anything failing part way — a full disk is the ordinary cause — went to catch (IOException e) and rethrew without closing.

Tests

BTreeIndexWriterCloseTest, three cases against a PositionOutputStream that counts closes and fails past a fixed capacity:

• testTheOwnerCleanupPathReleasesAnAbandonedWriter — runs the exact instanceof AutoCloseable idiom the owners use, against a writer that never reaches finish().
• testCloseIsIdempotent — SortedGlobalIndexWriter holds the task writer in a try-with-resources, so close() can follow a successful finish(); the stream must not be closed twice.
• testFinishReleasesTheFileWhenWritingFails — a write that fails mid-finish().

On master the first two fail and the third errors. Removing only Closeable from the class while keeping the close() method — so it still compiles and still has a way to be closed, just not one the owners can see — fails exactly one test, testTheOwnerCleanupPathReleasesAnAbandonedWriter with Expecting AtomicInteger(0) to have value: 1, which is what pins that the test discriminates the property being fixed rather than merely the presence of a method.

Worth noting for review: SortedGlobalIndexWriterTest already asserts this cleanup, in testSingleColumnWriterClosesActiveWriter and testBuildForSinglePartitionClosesWriterAfterFailure. Both build the subject with mock(GlobalIndexSingleColumnWriter.class, withSettings().extraInterfaces(Closeable.class)) — they add to the mock the one property the real class lacks — and the second names indexType btree but then overrides createWriter() to return that mock, so BTreeIndexWriter is never constructed. Both are green today.

mvn test -pl paimon-common -Dtest='org.apache.paimon.globalindex.**' — 349 tests, all passing. spotless:check and checkstyle:check clean.

Tests API and Compatibility

No API, format or configuration change. close() is additive and idempotent, so a successful finish() behaves exactly as before.

[JingsongLi]

[P2] Close the stream when constructor setup throws an Error

This constructor-cleanup guard still misses Error. In particular, new SstFileWriter(...) allocates its data and index block buffers after out has been opened, so an OutOfMemoryError leaves the constructor without returning an AutoCloseable object and strands the output stream. A task/runtime may catch that failure while keeping the JVM alive, just like the abandoned-build paths this PR addresses. Please catch and rethrow RuntimeException | Error (or use the usual catch (Throwable) constructor-cleanup pattern) so every post-open setup failure closes out.