feat(apple): give HtmlConfig's optional settings their real Swift types

[andiwand]

🤖 Generated with Claude Code

Closes #759.

HtmlConfig.spreadsheetLimit is a TableDimensions boxed in an NSValue, and Swift has no @encode, so a caller had to write:

config.spreadsheetLimit = withUnsafeBytes(of: TableDimensions(rows: 100_000, columns: 500)) {
    NSValue(bytes: $0.baseAddress!, objCType: "{ODRTableDimensions=II}")
}

That literal is a second source of truth for the struct's layout, sitting in a consumer — opendocument-app/OpenDocument.ios#185 carries it today — and a field added to ODRTableDimensions breaks it silently, because getValue:size: checks the size and not the encoding.

Now:

config.spreadsheetLimit = TableDimensions(rows: 100_000, columns: 500)
config.initialZoom = 1.5

How

The six boxed properties are marked NS_REFINED_FOR_SWIFT, so Swift sees them as __spreadsheetLimit etc., and apple/swift/Html+Optionals.swift — beside Style+Optionals.swift, which solves the read half — carries them under their own names as real optionals:

property	was	is
spreadsheetLimit	NSValue?	TableDimensions?
spreadsheetCellLimit	NSNumber?	UInt64?
spreadsheetViewportMode	NSNumber?	HtmlViewportMode?
viewportWidth	NSNumber?	UInt32?
initialZoom	NSNumber?	Double?
pageRangeEnd	NSNumber?	UInt32?

@encode stays in the ObjC layer, as an NSValue (ODRTableDimensions) category beside the struct it encodes. ObjC callers see the boxed properties unchanged.

Deviation from the issue's sketch

The issue proposed new names alongside the boxed ones (sheetLimit, zoom), the way Style+Optionals.swift renames fontColor → color. Refinement is better here: it keeps the names the API already has (no width/pageEnd coinages for properties whose names were already right), and it removes the boxed spelling from Swift rather than leaving both — so the encoding literal cannot be written again. It is the Apple-blessed mechanism for exactly this. apple/AGENTS.md records the rule.

This is a Swift-source-breaking change for anyone assigning the boxes, which today is the one workaround this PR exists to delete. CHANGELOG.md says so.

Verification

macOS slices built and ODR_XCFRAMEWORK=OdrCoreObjC.xcframework swift test: 23 tests, 0 failures, including two new ones — nothing under apple/tests set any of these before, so the write path had no coverage at all.

The end-to-end one renders a 3×2 csv (a csv renders as a spreadsheet, so it needs no fixture) with spreadsheetLimit = (rows: 2, columns: 1) and asserts the third row and second column are gone. Checked non-vacuous: with the limit at 99×99 both assertions fail as expected.