feat(xlsx): report numeric display overflow

[y4ho0]

Summary

• add a machine-readable numeric_overflow warning in the Format bucket when an explicit, width-stable xlsx numeric or date display cannot fit its visible column or merged-range width
• honor effective cell, row, column, and base styles; hidden surfaces; merged cells; shrinkToFit; Show Formulas; 1900/1904 date semantics; and remaining --limit capacity
• conservatively skip General and unresolved formats, rotated or shrink-to-fit cells, ambiguous 1904 date formulas, and negative 1900 elapsed values where widening is not a valid fix

Scope

Part 1 of #301 only. PPTX layout and spacing checks remain out of scope.

Refs #301

Validation

• dotnet run --project tests/OfficeCli.NumericFit.Tests/OfficeCli.NumericFit.Tests.csproj --configuration Release --no-restore (passed; only the existing ExcelHandler.SheetShift.cs:538 CS8602 warning appeared during the full rebuild)
• dotnet build src/officecli/officecli.csproj --configuration Release --no-restore (passed, 0 errors)
• public ViewAsIssues runner covers narrow and adequate widths, General and explicit formats, formulas, ISO and 1904 dates, built-ins 45-48, style inheritance, merges beyond renderer caps, hidden surfaces, shrinkToFit, non-finite values, and exact/bucket limits
• CLI black box: view issues --type numeric_overflow --json reported the narrow formatted value at /Sheet1/A1 with a machine-readable width suggestion
• git diff --check

[PeterZZZ]

Thanks for taking this on — this is Part 1 of #301, which we filed after measuring what whole-document HTML previews cost in an agent-driven audit loop: view html on a real workbook came back ~108 KB (truncated at our 64 KiB capture cap before the model ever saw the end of it), versus ~1.5 KB for view issues. In runs where an agent pulled the full HTML dump, on average ~190k tokens per run were replay of that single dump. A trustworthy numeric_overflow check in the Format bucket is exactly what lets automated audits stay on the compact path, so we're glad to see this.

One suggestion in that same spirit — output size scaling. If I'm reading CheckAllNumericOverflow right, findings are emitted per cell. The common real-world shape of this defect is columnar: one narrow column under a numeric/date format overflows in every data row, so a 5,000-row sheet yields 5,000 findings that all carry the same actionable fix (suggest.width=N on the same column). That has two costs for the audit use case:

• Without --limit, output scales with row count — reintroducing the large-output problem view issues almost replaces whole-document HTML previews for automated audits — two gaps: xlsx numeric-fit (###) and pptx layout/spacing checks #301 was trying to close.
• With --limit, duplicates of one column's fix can consume the entire remaining capacity in worksheet scan order, so the audit never learns that a different column (or sheet) also overflows.

Since the actionable fix granularity is per column (one width set), would you consider aggregating per (sheet, column): one finding carrying the affected-cell count and range, the worst-case cell (whose max required width is also the correct suggest.width for the whole column), and one representative display value? Roughly:

path:       /Sheet1/A
message:    numeric overflow in 4,832 cells (A2..A5000); worst '1,234,567.89' at 11.0pt needs 15.2 width, column A is 8.43
suggestion: suggest.width=16; widen column A to at least 16

Merged-range findings are already effectively per-range and could stay as they are. This bounds output by columns instead of cells, and --limit capacity then buys distinct fixes instead of repetitions of one.

To be clear, this doesn't have to block this PR — the detection mechanics wouldn't change, only the emission, so it could equally be a follow-up. Either way we're looking forward to it landing: we pin the officecli version downstream, and we'll route our xlsx audit gates onto numeric_overflow as soon as it ships in a release.

[y4ho0]

Thanks for the concrete scaling example. I agree that the actionable unit is the column: emitting one finding per cell lets a single narrow column consume the output and --limit, while a per-column aggregate can retain the worst required width and expose distinct fixes across sheets.

I’ll keep this PR focused on the detection mechanics that are already covered here, since changing finding paths and aggregation semantics would broaden it late in review. Once this lands, I’ll treat per-(sheet, column) aggregation as a separate follow-up with dedicated large-column and cross-sheet limit tests.