fix(tables): make calc_bbox_intersection safety_margin actually apply

[eeshsaxena]

Problem

calc_bbox_intersection(bbox1, bbox2, safety_margin=5.0) is meant to treat two boxes within safety_margin of each other as intersecting. But the "expanded boxes intersect" guard can never be true, so safety_margin has no effect:

x2_expanded_max = max(bbox1[2], bbox2[2]) + safety_margin
if x2_expanded_max <= max(bbox1[0], bbox2[0]) or ...:   # always False
    return None

max(right edges) + margin <= max(left edges) never holds, because every box's right edge exceeds its left edge (so max(rights) >= max(lefts) and the margin only widens the gap). The other three disjuncts are false for the same reason. The function then falls through and returns the intersection of the un-expanded boxes, so it only ever returns non-None when the original boxes strictly overlap — regardless of safety_margin.

Impact: ml.py builds table cells via calc_bbox_intersection(row.bbox, col.bbox, safety_margin=5). A row/column pair that is within 5px but not strictly overlapping (detection noise at cell edges) returns None, dropping the cell.

The existing test even documents this — two cases were "adjusted to expect None" to fit the broken behavior:

# Test case 2: Intersecting with margin - adjusted to expect None for a point intersection
((10, 10, 20, 20), (20, 20, 30, 30), 5, None),  # Adjusted expectation

Fix

Expand each box by safety_margin, then intersect the expanded boxes — the same tolerance pattern used by Element.overlaps() elsewhere in the codebase. This makes safety_margin take effect while leaving the margin=0 and strictly-overlapping cases unchanged.

The two "adjusted" test cases now assert the correct margin-expanded intersections ((15,15,25,25) and (21,21,25,25)), and I added a far-apart case that stays None to pin the tolerance boundary.