Device round 3: verify the post-fix wire/ack shape on the native engine, pin the clear gap under real LepusNG, and close two data-quality questions from #41

Follow-up to the #41 campaign, for the session holding the `aries_10` device. Four parts; A and B are device windows (Huxpro/octane#194 protocol: thermal gate, lease receipts, DevTool per round-2 configuration), C and D are harness-side checks with no device needed. Native results follow Harness separation exactly as before — nothing here enters or reorders a web lane.

## A — Post-fix native cells (the #229/#233 fixes have only ever been proven on web)

Build the Octane native bundle from `Huxpro/octane` `new-lynx` @ `8938c1260` (record the exact source as in #41). One lease:

1. **create → clear → re-create @1k**, capturing `wireToBtsBytes`, `wireToBtsMsgs`, and the MTS→BTS ack count per commit. Web says the compact-ack storm (23,799 msgs / 17.4MB) and the first-tree cliff are gone (~770B constant, 2–3 msgs); this confirms the same shape under LepusNG, where the ack path used to be the 8.5-second ledger.
2. **The ~7,000-row boundary probe** from Huxpro/octane#234 Part A (just under the predicted PaintingContext line), if it fits the same lease — it shares the build.

Expected: byte/msg counts match the web lane's constants. Any ack-count regression on device that web does not show is a new finding — report it with the raw counts, don't average it away.

## B — `clear` under the real interpreter (the #41 discovery this device can uniquely confirm)

#41 found `clear` costs the octane family 2.6–4× the peers' JS volume, **regime-invariant** — which predicts the same ratio under LepusNG. One window: `clear @1k` (and @10k only if the eager paint survives — it may hit the ART ceiling first, DNF is fine and is itself data) for **octane-hux, upstream octane, ReactLynx** at minimum.

- Ratio holds on device → the web-interp lane is validated as a predictor for this cell, and Huxpro/octane#241 gets its device stake.
- Ratio differs materially → the interp lane's fidelity has a boundary; record where, that's calibration gold either way.

Also fold both A and B into the rank-stability calibration section shipped in #41 — these are the first **post-fix** native anchors, and the calibration should say which anchors are pre-fix vs post-fix.

## C — btsCpu is not self-consistent across lanes (suspend the metric until answered)

From the #41 records, `btsCpu`/create@10k: JIT lane hux=493 vs upstream=115 (4.3×), but interp-4x **inverts** to hux=120 vs upstream=422. CPU spent cannot drop 4× when the CPU is throttled 4× — one of these numbers is not measuring "BTS CPU". Check the measurement boundary: sampling window, idle attribution under throttle, whether the throttle applies to the worker the BTS runs in, and whether the boundary is identical across entries. Outcome: either a corrected definition (and re-run of the affected cells) or a documented invalidation of btsCpu under throttle. Huxpro/octane#230's btsCpu lead is suspended pending this.

## D — react's startup advantage needs a boundary check

react FCP beats not just octane (~1.6×) but every vue variant by 40%+ in all three lanes — an outlier that smells like a measurement-boundary difference rather than a framework one. Verify the react entry's startup path measures the same thing (same navigation start, same first-paint predicate, same bundle-serving path) as the other entries. If it does, say so and the number stands; if not, fix and re-run startup only.

Report A/B to Huxpro/octane#194 (device evidence home) with a pointer from #40; C/D as a comment here.

Start with the Huxpro/octane new-lynx build at commit 8938c126 and the records from #41; use #194 and #234 for the device protocol and boundary probe context. Run the native A/B cells and investigate the btsCpu and React startup measurement boundaries across lanes. Done means raw A/B results are reported, calibration distinguishes pre- and post-fix anchors, and C/D are either validated or explicitly invalidated with rerun requirements.

Written by the indexing model from the issue text.