[BUG] delete_partition followed by re-insert silently loses data under Non-Blocking Concurrency Control #19793

Bug Description

What happened:

Under Non-Blocking Concurrency Control (NBCC), performing a delete_partition on a partition and then re-inserting rows into that same partition results in silent data loss — the re-inserted rows are written to storage but become invisible to all readers, with no error raised.

This is the same underlying invariant violation as #19791 (insert overwrite under NBCC), but reached through a different operation pair. #19791 deliberately scoped its fix to insert overwrite only; this issue tracks the broader root cause.

What you expected:

When a bucket's fixed file group is retired by a replacecommit, subsequent NBCC writes to that bucket should land on a fresh file id (e.g. bump the trailing -0 generation in newBucketFileIdForNBCC / the bucket-id-getter) so the new file group id no longer matches the retired one. This fixes both the insert overwrite and delete_partition+re-insert cases at the source. Needs careful thought on compaction, log-file grouping, and reader-side bucket resolution.

Steps to reproduce:

1. Create a MOR + simple-bucket table with hoodie.write.concurrency.mode = NON_BLOCKING_CONCURRENCY_CONTROL.
2. Insert some rows into partition p.
3. Run delete_partition on p. This produces a replacecommit that records bucket p's fixed file id (…-0) as replaced.
4. Re-insert rows into partition p. NBCC routes them to the same fixed file id.
5. Query the table.

Expected: the rows from step 4 are visible.
Actual: the rows from step 4 are silently invisible — the file system view still treats that file group id as replaced by the step-3 replacecommit, so it filters the freshly written slice out. No error is raised.

Environment

Hudi version:
Query engine: (Spark/Flink/Trino etc)
Relevant configs:

Logs and Stack Trace

No response