fix(manifest): reject row ID allocation overflow

[fallintoplace]

What changed

Validate every row-ID range assigned by the v3 manifest writers before advancing the cursor:

• reject negative initial row IDs
• reject negative added or existing row counts
• detect int64 overflow while allocating a manifest range
• advance NextRowID only after manifest validation and encoding succeed

The same checked arithmetic is used by WriteManifestV3 when it returns the next available row ID.

Why

V3 row lineage requires non-negative row IDs. The manifest-list writer previously added existing_rows_count and added_rows_count directly to its cursor. Near math.MaxInt64, that addition could wrap and assign a negative first_row_id to the next manifest. Invalid counts or a later validation failure could also move the in-memory cursor even though the manifest was rejected.

This could produce overlapping or invalid row-ID ranges in metadata written near the boundary.

Testing

• negative initial row ID
• negative manifest row count
• manifest-list range overflow
• WriteManifestV3 range overflow
• cursor remains unchanged after overflow or later validation failure
• go test .
• go vet .