Fix chars_in_rect pairing top-down rects with top/bottom

[BetterAndBetterII]

Summary

• chars_in_rect() compared a top-down rect (rect[1] top, rect[3] bottom) against CTM y0/y1. Short tables and non-identity CTMs then failed the text-in-rect check and were dropped from find_tables().
• Pair rect[1]/rect[3] with c["top"]/c["bottom"], matching has_text() in the same file.
• Fixes [BUG] Coordinate key mismatch in pymupdf.table.chars_in_rect() drops table candidates and rows #5092

Test plan

• RED then GREEN: synthetic char with top/bottom inside rect and y0/y1 outside is now detected
• tests/test_tables.py — test_5092 and test_table2 passed

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[BetterAndBetterII]

I have read the CLA Document and I hereby sign the CLA

[veget-able]

Thanks for the fix!

I also tested this against our 503-page table benchmark.
The change looks correct to me. The overall GTRM moved only slightly, from 0.721066 to 0.720618, with just 4 of 503 pages changing.

Looking at those pages individually, one improved significantly, one regression appears to be a ground-truth mismatch, and the remaining two exposed pre-existing edge cases in the refine pipeline that were previously masked because these candidates were being rejected.

So I don't think the small benchmark regression is a reason to hold this fix.

[veget-able]

@JorjMcKie
It looks like the CLA check is incomplete because @cursoragent is included as a committer and cannot sign it.

We may run into this more often with agent-assisted PRs, so I think it would be worth deciding how we want to handle agent accounts in the CLA process going forward.

[julian-smith-artifex-com]

There's a cla-assistant issue for this: cla-assistant/cla-assistant#1190, but it only has two comments (including my new one).