fix(ohos): pull-to-refresh contentInset offset rests at 0 under margin model, not -inset.top

[bytemain]

Problem (Raft task #110)

On OpenHarmony, the Activity pull-to-refresh showed a ~2× (~180dp) top blank that stayed for the entire refresh, with the spinner centered in it. Android/iOS are unaffected.

Root cause

OHOS realizes KRScrollerView contentInset as an ArkUI margin (a physical top shift). But SetContentInset's animate path snaps the content offset to MaxContentOffsetInContentInset, whose top-overscroll branch returns {0, -content_inset->top} — the iOS resting-offset semantics — and then applies SetArkUIMargin(top=inset.top). During a held refresh inset (top=80), offset -80 + margin 80 double-count = 160vp ≈ 180dp = 2×. iOS is correct because its native contentInset shifts the coordinate origin (no margin); this file is core-render-ohos only.

Fix

Under the margin model the top resting offset is 0, so clamp top-overscroll to {0, 0}. Release then settles to offset 0 + margin 80 = 1×; the recycle path (inset top=0) still clamps a residual negative offset to 0.

• MaxContentOffsetInContentInset is used only by SetContentInset → low blast radius, normal scroll/inertia clamps untouched.
• The symmetric horizontal start branch is the same latent class but is not exercised by task fix(compose): redraw restored lazy descendants #110 (vertical/top); left as a separate follow-up, intentionally not bundled.

On-device verification (HOP-AL10, HarmonyOS)

• Product PASS (artin, hands-on): the stuck ~2× blank is gone → now 1×. The remaining transient — pull reaches 2× while the finger drags, then bounces back to 1× on release — is standard pull-to-refresh (Android baseline behaves identically), not the bug.
• Provenance / single-variable knife: device base 53e5892fd pins fork b57fc344 (this PR's parent) via gitlink + kuikly-render-staging2-b57fc344.har; candidate carrier ecf8d9816 advances only that fork to 19f29487. Native libkuikly.so BuildId changed e4077a2b… → bfa3d280… (HAP 5c0fd527…), proving the device runs this exact change and not a stale HAR — the only runtime delta is this one commit.
• Control-flow proof: post-fix there is no vertical top-overscroll path that returns -inset.top, so a release-time offset -80 + margin 80 (2×) is impossible by construction; the observed transient 2× can only come from finger-driven overscroll during the drag.

Credits: localization @赵梓淇/Cindy · Android oracle + repro @pixel · device verification & build provenance @ark.

Author: HanXin (see Signed-off-by). Per our flow the author does not self-merge — a permitted maintainer presses.