Use numeric doc values for Lucene-to-Pinot document ID mapping - #19897

Reviewed the Lucene-to-Pinot docId mapping change (correctness, mixed-version compatibility, concurrency). The core approach is sound and well tested.

I verified against Lucene 9.12 source that the MultiDocValues.getNumericValues + monotonic advanceExact(i) loop is correct for the mixed-leaf case: advanceExact sets docID = target before the null-value check, so the forward-only target >= docID() contract is never violated even when a leaf lacks the field, and the merged view uses the same global maxDoc-space ordinals as storedFields().document(i), so both paths address the same document. Forward compatibility also holds: doc values are not stored fields, so an older reader's stored-field iteration (and its single-stored-field assertion) is unaffected by the new index, and a newer reader falls back cleanly on older/mixed indexes. The one standing invariant to keep is no-deletions on the sealed index (maxDoc == numDocs), which is already relied on and guarded elsewhere in the reader.

LGTM — no blocking issues. Two minor, non-blocking consistency nits noted inline on the creator's fallback path. (Posting as a comment rather than a formal Approve because this review is running under the PR author's token, which GitHub does not allow to self-approve.)

Re-reviewed on the new push (2c07d0f). This revision resolves both minor nits I raised on the previous commit's buildMappingFile:

• StoredFields is now hoisted and lazily cached once outside the loop instead of being re-created per fallback document, matching the reader's fillDocIdMapping.
• The fallback now guards a null stored docId and throws a clear IOException("Missing Pinot document id for Lucene document: " + i) before Integer.parseInt, so the creator and reader paths behave consistently on a corrupt index.

It also tightens exception chaining (passing the cause instead of string-concatenating it) and adds testConvertMutableSegmentRejectsMissingStoredDocId, a focused regression test that asserts the new guard fires with the expected root-cause IOException and message.

The core doc-values mapping algorithm is unchanged from the version I verified against Lucene 9.12 source, and the delta is a clean, well-scoped follow-up. LGTM, no outstanding issues. (As before, this is posted as a comment rather than a formal Approve because the review runs under the PR author's token, which GitHub does not allow to self-approve.)