fix(compaction): batch filename collision causes up to 84% data loss …

[xe-nvdk]

…(#357)

When partitions had >30 files, SplitCandidateIntoBatches created sequential batches of 30. Each batch generated output filenames with second-precision timestamps, causing all batches within the same second to produce identical filenames. Each batch overwrote the previous, destroying up to 84% of data.

Fixed by adding UnixNano to compacted filenames for guaranteed uniqueness. Updated extractNewestFileTime to handle both old and new filename formats.

[xe-nvdk]

Fix already merged into main via PR #358. This release branch was a cherry-pick for the v26.03.2 hotfix.

[gemini-code-assist]

Code Review

This pull request updates the compaction process to include nanosecond timestamps in generated filenames, preventing data loss from file overwrites during sequential batch runs. Corresponding changes were made to the file time extraction logic to support parsing these new formats. A review comment suggests correcting a descriptive comment to accurately reflect the new filename structure.

[gemini-code-assist]

The comment on this line describes the tier-compacted file format as measurement_YYYYMMDD_HHMMSS_{nanos}_{daily|compacted}. However, based on the new filename generation logic in job.go, the _nanos part is inserted before the _daily or _compacted suffix. A more accurate description of the filename structure (before stripping the .parquet extension) would be measurement_YYYYMMDD_HHMMSS_nanos_{daily|compacted}. Updating this comment would improve clarity and consistency with the actual file naming convention.

Suggested change

	// Check if it's a tier-compacted file: measurement_YYYYMMDD_HHMMSS_{nanos}_{daily|compacted}
	// Check if it's a tier-compacted file: measurement_YYYYMMDD_HHMMSS_nanos_{daily|compacted}