extract_text_with_positions Python page filter has inconsistent page indexing

Summary:
The Python positioned-text API appears to expose an internal one-based page filter, while callers naturally pass zero-based page indexes.

Observed behavior:
Calling:

pdf_inspector.extract_text_with_positions(path, pages=[0])

did not select physical PDF page 1 as expected.

In a local fix, normalizing the Python binding’s input/output page indexes to zero-based caused physical page 1 to return 270 positioned text items, with returned records reporting page 0.

Expected behavior:
The Python API should use one clearly documented page-index convention for both:

input filters
returned page values

Ideally this should be zero-based to match normal Python indexing, unless the project intentionally chooses one-based indexing and documents it consistently.

Why this matters:
The mismatch can silently return data from the wrong physical page or no data at all, which is especially difficult to diagnose in page-filtered workflows.

Regression test idea:

items = extract_text_with_positions(pdf, pages=[0])
assert items
assert all(item.page == 0 for item in items)

A multi-page fixture could additionally verify:

pages=[0] → first physical page
pages=[1] → second physical page

Local fix tested:
Normalise page-filter input/output in the Python binding so the public Python API consistently uses zero-based page indexes.

Start at the Python binding entry point for extract_text_with_positions and trace how pages is passed into extraction and how returned page values are assigned. Run the existing Python tests with a multi-page PDF, then add the proposed regression checks for pages=[0] and pages=[1]; done means filtering and returned page values consistently use the documented zero-based convention.

Written by the indexing model from the issue text.