Details refresh: in-place row updates, one system read per figure per tick (#161)

[almothafar]

Problem 1 — full table rebuild every 3 s

BatteryDetailsFragment now keeps its rows in a label-keyed registry and each refresh updates the value cells in place; rows are created/removed only when their label genuinely appears or vanishes (rate warm-up, time-to-full gating, capacity turning unknown). Accessibility focus, scroll position and the view tree survive refreshes.

• The diffing lives in a static, binder-driven syncRows helper — covered by the new BatteryDetailsRowSyncTest (steady-state reuses the same view instances; vanished keys remove only their row; appearing keys insert at the right position, including mid-table).
• Value-cell decorations (the Battery health: show 'Unknown' + tappable info when the charge gauge is unreliable (vs design capacity) #94 unreliable icon, the Show battery charge/drain rate (e.g. "9%/h") in details table and status notification #108 rate colour) are re-applied and cleared on rebind via a shared applyValueDecorations, so a row toggling state can''t keep a stale icon/colour.
• One-time table setup (column stretch, paddings) moved out of the refresh path.

Problem 2 — redundant system reads per tick

• BatteryDO now carries the OS cycle count (EXTRA_CYCLE_COUNT, normalized to -1 like getChargeCycleCount) extracted from the same intent as everything else — pinned by SystemServiceTest.SnapshotCycleCount.
• The fragment passes the snapshot''s capacity and cycle count into new BatteryHealthTracker overloads (isBatteryReadingUnreliable(context, mAh), getEffectiveCycleCount(context, osCycles)) — no second capacity estimate, no sticky re-read on the 3s tick.
• Insights (updateHealthData) now does one sticky read + one capacity estimate per refresh, feeding everything through isCycleCountFromOs(osCycles), getMeasuredHealthPercentage(context, mAh) and the new pure cores estimatedHealthForCycles / gradeForCycles (parameterized tests pin the degradation curve and grade boundaries to each other).

Problem 3 — findViewById per tick in MainActivity

The gauge and the details fragment are fields set once in onCreate, like batteryInsightsButton already was; refreshBatteryUi, onPostResume, onPause, initializeFirstValues and the slider callback all use them.

Tests

testDebugUnitTest (407 tests, 24 new) + lintDebug green; debug build installed on the Mate 10 Pro.

On-device check: with the screen open, watch the details table across a few refreshes — values tick without the table flashing/scroll jumping, rate/time-to-full rows still come and go correctly, and the capacity "Unknown ⚠" affordance still opens its dialog.

Closes #161

🤖 Generated with Claude Code