Fix IndexOutOfBoundsException caused by concurrent sort and delete on TVList

[shuwenwei]

Description

Fix IndexOutOfBoundsException: Index 0 out of bounds for length 0 thrown in
AlignedTVList.deleteTime() / delete() when a DELETE races with a query that
sorts the shared working TVList in place.

Root cause

• Query path: FileLoaderUtils.loadAlignedTimeSeriesMetadata() -> ...
  -> AlignedReadOnlyMemChunk.sortTvLists() calls AlignedTVList.sort() in
  place on the shared (still writable) working TVList. sort() is
  synchronized on the TVList instance and rebuilds indices non-atomically
  (indices = new ArrayList<>() then fills it).
• Delete path: AlignedTVList.deleteTime() / delete() were not
  synchronized, so a concurrent DELETE could call getValueIndex(0) ->
  indices.get(0) while indices was momentarily empty ->
  IndexOutOfBoundsException, or read half-rebuilt indices and silently delete
  wrong rows.

Fix

Make delete() / deleteTime() / delete(column) / deleteColumn() of
AlignedTVList (and TVList.delete() for the non-aligned path) synchronized
on the same TVList instance as sort(), matching the existing monitor already
used by putAlignedValue / clone / cloneForFlushSort.

Delete path audit

All runtime delete paths converge to TsFileProcessor.deleteDataInMemory()
which holds flushQueryLock.writeLock():
DataRegion.deleteByDevice / deleteDataDirectly ->
deleteDataInUnsealedFiles / deleteDataInSealedFiles /
deleteDataDirectlyInFile -> TsFileProcessor.deleteDataInMemory ->
AbstractMemTable.delete -> AlignedWritableMemChunkGroup.delete/deleteTime ->
AlignedTVList.delete*.

WAL recovery paths (TsFilePlanRedoer, UnsealedTsFileRecoverPerformer) call
memTable.delete() directly but only during single-threaded startup, so no
concurrent query/sort exists there.

Lock order stays consistent (flushQueryLock -> tvlist monitor on both delete
and query-clone paths; query in-place sort holds only the tvlist monitor because
the read lock is released before sortTvLists() runs), so no deadlock is
introduced.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 43.28%. Comparing base (d82806f) to head (6ea4c3e).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #18389      +/-   ##
============================================
- Coverage     43.46%   43.28%   -0.19%     
  Complexity      374      374              
============================================
  Files          5364     5394      +30     
  Lines        383224   385138    +1914     
  Branches      49868    50087     +219     
============================================
+ Hits         166560   166692     +132     
- Misses       216664   218446    +1782     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.