Say what a sheet leaves out, and cut it to what the device can show

[andiwand]

Closes #637, in the shape the measurement on that issue left it: the app says what a sheet leaves out, and leaves out less of it — but there is no button offering to relax the cut, because nothing a phone can do lies behind one.

What a reader sees

A sheet the budget cut raises a bar naming the numbers, for the sheet on screen and again when a tab is selected; moving to a sheet that is whole takes it down. Both verified on a 2 GB device, where the budget is 50,000 cells:

This sheet is too big to show in full. Showing the first 5,000 of 20,000 rows.

Columns get their own string, and a sheet cut both ways gets one naming both. The numbers are HtmlView.sheetCut()'s — the extent the cells span against the extent the markup carries — grouped for the reader's locale.

What the limit is now

SpreadsheetBudget answers per device: 50,000 cells below 3 GB of memory, 100,000 below 6 GB, 150,000 above, against 500,000 for every phone before. ROWS/COLUMNS still bound the two directions on their own.

It is a cut rather than the raise the issue proposed because the budget is the WebView's, not the core's. Measured on a 2 GB API 31 emulator and an 8 GB API 36 one:

	app process	renderer process	what the user gets
the 4.5 MB odr-public register, old limit, 2 GB	819 MB	died mid-stream	"Couldn't open this file" after ~80 s
the same, old limit, 8 GB	965 MB	4.7 GB	renders, and the system UI stops responding
the same, twice the old limit, 8 GB	1.19 GB	5.07 GB	renders, unresponsive again
a 20,000-row csv, new limit, 2 GB	249 MB	489 MB	renders, with the bar above

A rendered cell costs 10-20 KB in the renderer against some 226 bytes of html, so a limit above what can be laid out does not show more of the document — it shows none of it. The full ladder, both devices and the failure modes are in the comment on #637.

The lever that would move the ceiling itself is core-side, and filed as opendocument-app/OpenDocument.core#822: 55% of a sheet's html is style attributes drawn from 26 distinct strings, and inline style is the one shape a browser engine cannot share between elements. If that lands, these steps are worth measuring again.

Shape of the change

• SheetCut — parcelable, four numbers, the core's own answer.
• CoreLoader.host() puts it on HostedView; render() carries it into LoadedDocument.partCuts, running alongside partTitles/partUris with a null for every part that is whole.
• SpreadsheetBudget replaces the three constants in CoreLoader, with cellsFor(totalMemoryBytes, isLowRamDevice) split out so the ladder is a unit test rather than a shelf of phones.
• DocumentFragment.reportSheetCut raises and dismisses the bar; SnackbarHelper grew a message overload, since this is the first bar whose text carries numbers.

Nothing new is a setting: per CLAUDE.md, how a document is displayed is answered over the document, and this one is not even that — it is what the device can hold.

Checks

spotlessCheck, lintProDebug, assembleDebug, testProDebugUnitTest, and connectedProDebugAndroidTest on a 2 GB API 31 emulator: 91 tests, the three LandingTests failures pre-existing on unmodified main on that AVD (swipe, undo and intro on the landing list — checked by stashing the change and running them again).

New tests: SpreadsheetBudgetTest for every step of the ladder, CoreTest.aSheetPastTheBudgetSaysWhatItLeftOut (a csv generated to the device's own budget, since a fixture big enough on one device is too small on the next) and aSheetInsideTheBudgetReportsNoCut, plus the cut through DocumentParcelTest.

🤖 Generated with Claude Code