feat(html): let a host ask the view to measure the fit itself

[andiwand]

🤖 Generated with Claude Code

Stacked on #744 — review that first; base moves to main once it lands.

Mode (4) from #726: the view measures the fit and keeps it current, at the top level, opt-in.

What it does

HtmlViewportMode::fit_width_by_view writes --odr-fit:view, which drops the framed condition in the script, and pins initial-scale=1.0.

The meta tag is the part #726 does not mention, and it is what makes this one switch rather than a negotiation: loadWithOverviewMode only fires where the page has not stated a scale. So droid does not have to turn it off, ios has nothing left for its user script to correct, and no host can end up fitting the document twice.

The three existing modes are untouched — automatic and fit_width still leave a top-level document to the meta tag, so nothing in the 377 public reference renders moves (full suite run below).

viewport_width set alongside it loses: view means the view keeps the fit current, which is the opposite of freezing a factor into the css. A host under a CSP that cannot run the script wants viewport_width and not this mode.

The internal shape

fits_width → width_fit, returning WidthFit::{none, host, view}. The question stopped being yes/no — #726 puts it as three modes where four are wanted — and a tri-state makes the contradictory combinations unrepresentable rather than something callers have to not write.

The enumerator is appended after none: apple casts the enum to NSInteger and jni maps it by ordinal, so the existing values stay put.

Verification

• odr_test in full: 1199 tests, 1193 passed, 6 pre-existing skips — including the 280 reference-output comparisons, so no existing render moved.
• New: html_common.fit_width_by_view_pins_the_scale_the_browser_would_fit, html_common.the_view_measures_the_fit_where_it_was_asked_to, width_fit_follows_the_resolved_mode extended, and a case in html.paged_output_fits_the_viewport.
• jni: viewportModeReachesTheHtml extended and run green.
• Browser, test/browser/viewport/, a 2400px page: top level --odr-fit:view opens at 0.63 with no overflow in a 1512px window and refits to 0.3333 when the window goes to 800 — and --odr-fit:auto at the top level still opens at 1 and overflows, which is the behaviour this must not change. Framed, both fit. tests.html links the two top-level pages since a frame cannot tell the modes apart.

Not run here

• No device. Neither an ios simulator nor an android emulator. What The live fit is gated on being in a frame, so a top-level host can only have it frozen (viewport_width) #726 says this mode buys the apps — the ios user script deleted, loadWithOverviewMode turned off — is unmeasured from this side.
• python and wasm bindings compile-checked only by inspection: the build dir's venv is gone and wasm needs emscripten. Both are a one-line enum registration beside three identical siblings. The apple binding does compile here, so its ODR_SAME_ENUM ordinal asserts hold.
• The python test added alongside them has not been run.