`page_number` in `RecursiveDocumentSplitter` points to the page the chunk ends on

[bogdankostic]

Summary

While reviewing #12909, I noticed that our three text splitters disagree on what page_number means.

• DocumentSplitter → the page the chunk starts on
• MarkdownHeaderSplitter → the page the chunk starts on (since fix: MarkdownHeaderSplitter page_number drifts upwards when split_overlap is used #12619)
• RecursiveDocumentSplitter → the page the chunk ends on

Verified on main (8de125819), same 3-page source in each case:

splitter	chunk	spans	reported
DocumentSplitter	'aa bb\fcc '	pages 1→2	1
MarkdownHeaderSplitter	'# H1\nAAAA\fBBBB\n'	pages 1→2	1
RecursiveDocumentSplitter	'AAAA\fBBBB'	pages 1→2	2

So a chunk that is 95% on page 1 with a few characters spilling onto page 2 reports page 1 in two splitters and page 2 in the third. Since page_number is what users show as "this answer came from page N", the difference is user-visible.

Why now

#12909 fixes a bug in RecursiveDocumentSplitter: with split_overlap > 0 a \f inside an overlapping tail was counted once per chunk, so page numbers drifted upwards and could exceed the document's page count.

The PR's patch is on top of the end-of-chunk convention.

Prior art

@dylanpulver already proposed a fix for this in #12590. It was auto-closed after two weeks because the CLA was never signed.

[michaelkillgta]

Hi! I'd like to take this. Plan is to align RecursiveDocumentSplitter with DocumentSplitter and MarkdownHeaderSplitter so page_number is the page the chunk starts on, with tests covering a multi-page source and overlap. I'll sign the CLA before opening a PR. @TimurRakhmatullin86 — your #12909 fixes the overlap double-count on the current end-of-chunk convention; happy to rebase on top of that (or wait for it to land) so we don't fight each other.