cpimport leaks open column segment files when a bulk load aborts (LeakSanitizer report in CI)

LeakSanitizer failed the ASanRegr stage of nightly build 3952 (stable-23.10, ubuntu:24.04, 10.6-enterprise) with a leak in cpimport:

• Direct leak: 4 BufferedFile objects (256 B) + 316 B indirect, allocated via FileOp::openFile <- ColumnOp::openColumnFile <- ColumnInfo::setupInitialColumnExtent <- BulkLoad::preProcess.
• Report artifact: https://cspkg.s3.amazonaws.com/stable-23.10/cron/3952/10.6-enterprise/amd64/ubuntu24.04_ASanRegr/core/asan.writeengine.2838103
• CI build: https://ci.columnstore.mariadb.net/mariadb-corporation/mariadb-columnstore-engine/3952 (stage 22)

Root cause: ColumnInfo owns the column segment file handle (curCol.dataFile.pFile, raw IDBDataFile*), but ~ColumnInfo() never closes it — only the normal load-completion path calls closeColumnFile(). When a bulk load aborts after the column files were opened (in build 3952 the import was interrupted by an unrelated test211 hang and stack restart), the ColumnInfo objects are destroyed with the files still open, leaking the IDBDataFile objects and their descriptors.

The leak is small (~572 B once, in a short-lived process) and only occurs on the abort path, which is why it appears sporadically in CI: the leak itself is deterministic, the abort trigger is not. Any aborted import under ASan will fail the sanitizer gate.

Fix: close the file in ~ColumnInfo() via the base-class ColumnInfo::closeColumnFile(false, /abort/ true). Abort semantics only release the handle — no flush/finalization (the compressed override is deliberately not dispatched from the destructor) and no extent-map interaction, so it is destructor-safe.