fix(xlsx): checked arithmetic in get_row_and_optional_column

[Svector-anu]

summary

get_row_and_optional_column backs get_dimension/get_row_column/get_row - the worksheet dimension and merged region parsing paths. it accumulates the base-26 column value and base-10 row value with raw */+. a range string with a long enough run of letters or digits overflows u32 during accumulation and panics (attempt to multiply with overflow) instead of returning an error.

Reference::parse already guards the same input class via wrapping_mul/wrapping_add plus a post-hoc validate() bounds check (see test_parse_reference_overflow). get_row_and_optional_column's callers don't do a follow-up bounds check, so checked arithmetic that fails right at the overflow site is the more self-contained fix here - reusing the ColumnNumberOverflow/RowNumberOverflow errors that already exist for the same condition elsewhere in the file.

how this was found

fuzzing a downstream consumer's xlsx target (seeded from its own test fixtures) crashed within a couple minutes:

thread '<unnamed>' panicked at calamine-0.36.1/src/xlsx/mod.rs:2837:38:
attempt to multiply with overflow

call stack: get_dimension -> get_row_and_optional_column, reached while parsing a crafted xlsx's xl/worksheets/sheet1.xml.

no memory-safety impact - rust panics safely - but any service converting untrusted spreadsheets through calamine can be crashed by a small file, since a release build without overflow checks would instead silently wrap into a bogus column/row value with no validation downstream of this function.

what's included

• checked arithmetic in both accumulation loops, reusing the existing ColumnNumberOverflow/RowNumberOverflow variants
• a regression test (test_get_row_and_optional_column_overflow) reproducing the panic pre-fix, plus a get_dimension case through the actual crash path
• cargo test --lib (43 passed) and cargo clippy --lib -- -D warnings both clean

open to matching Reference::parse's wrapping+validate pattern instead if you'd rather - went with checked arithmetic mainly because this function's callers don't validate the result afterward.

[jmcnamara]

Is this similar to #696?

[Svector-anu]

yeah, same root cause - unchecked u32 accumulation in get_row_and_optional_column. #696 predates this by a couple weeks and is further along (already reworked per your feedback to validate against the actual row/column limits instead of just catching the overflow). closing this one in favor of that.