fix(label-file): align fractional Mask bounds between read validation and export

[wkentaro]

This was generated by AI during triage.

Found while reviewing PR #2473 (issue #2453). The read-boundary validation added there rounds fractional Mask bounds, but the export helpers in the label-file module truncate them. The two paths should share one convention. PR #2464 (issue #2336) already settled on int(round(...)) for AI mask bboxes in _automation; the label-file export helpers should follow the same rule so a saved and reloaded Mask keeps identical bounds.

Origin: review finding on PR #2473, left out of that PR because it sits outside the GUI loading boundary.

[wkentaro]

This was generated by AI during triage.

Confirmed as a real defect, but the body's framing is off in two places and the brief below supersedes it. Checked against origin/main:

• The read validation merged in fix(label-file): reject malformed Shape semantics during read #2473 does not round Mask bounds. It deliberately declines to validate mask extent at all, and says so in a comment: extent drift is reachable through vertex edits in released versions, so rejecting it would make legitimately saved files unopenable. So there is no read-side convention to align to.
• The truncation is not in the label-file module. _dump_shape_to_json_obj only base64-encodes the mask and does no bounds arithmetic. The truncation lives in the shape-utility rasterizer used by the label-image exporters.

The genuine inconsistency is between that rasterizer and every other place fractional Mask bounds become pixel indices, which all round.

Agent Brief

Category: bug
Summary: Mask export truncates fractional bounds while construction and hit-testing round them, shifting exported masks up to one pixel from where the canvas draws them

Current behavior:
The shapes-to-label rasterizer converts a Mask Shape's two bound points to pixel indices with a NumPy integer cast, which truncates toward zero. Everywhere else that maps fractional Mask bounds to pixels rounds instead: the automation geometry helper rounds detection bounding boxes before building a Mask Shape, and the canvas hit-test rounds a cursor offset against the Shape's first point.

Fractional bounds are reachable in normal use, because read validation accepts fractional coordinates by design and vertex drags produce them. When they occur, the exported label image is placed up to one pixel away from where the canvas shows the Mask. Negative coordinates diverge worse: truncation moves them toward zero while rounding moves them to the nearer pixel, so the two conventions disagree in opposite directions.

Desired behavior:
The rasterizer maps fractional Mask bounds with the same round-half-away-from-zero convention as the rest of the codebase, so a Mask that is saved, reloaded, and exported keeps the placement the canvas renders. Clipping of out-of-image bounds and the mask-array slicing that follows must stay consistent with the rounded origin, not the truncated one.

Note this intentionally changes exported label images for Annotation Files with fractional Mask bounds. That shift is the fix, not a regression, and belongs in the CHANGELOG under ## [Unreleased] / ### Fixed with the PR link.

Key interfaces:

• The shapes-to-label conversion in the shape-utility module, specifically the shape_type == "mask" path that derives (x1, y1), (x2, y2) from points
• The existing bbox rounding helper in the automation geometry module. Reuse it if it fits without creating a layering dependency from the utility module onto automation; otherwise mirror its convention rather than inventing a third one
• No change to ShapeDict, the on-disk JSON schema, or the read path

Acceptance criteria:

• Mask Shapes with integer bounds produce byte-identical label images to before the change
• Bounds with a fractional part at or above .5 round up, below .5 round down, matching where the canvas places the Mask
• Negative fractional bounds round to the nearer pixel rather than toward zero, and stay clipped to the image
• The mask-array slice offsets stay aligned with the rounded origin, so no row or column of the stored mask is dropped or duplicated
• A unit test covers integer, round-up, round-down, and negative fractional bounds
• Existing export and label-file tests pass unchanged
• CHANGELOG entry added under ## [Unreleased] / ### Fixed with the PR link

Out of scope:

• Adding read-time validation of Mask extents. fix(label-file): reject malformed Shape semantics during read #2473 declined this on purpose and the reasoning still holds
• The oriented-rectangle self-crossing question in Decide read-validation strictness for self-crossing oriented rectangles #2480
• The mask-to-oriented-rectangle extent contract in fix(_automation): oriented rectangle can omit pixels from rotated masks #2337
• Rounding behavior of shape_to_mask for non-Mask Shape types

[wkentaro]

Correction to the Agent Brief: the existing bbox convention is ties-to-even via int(round(...)), as pinned by test_round_bbox_to_int_uses_ties_to_even_for_tuple_and_array, not round-half-away-from-zero. PR #2504 follows that convention and now covers an exact .5 origin. Read the rounding acceptance criterion as: fractional bounds round to the nearest integer with ties-to-even, matching existing Mask construction.