Charging: Record the HONOR external-write follow-up in the ledger

[d4rken]

What changed

No user-facing behavior change. This records new contributor evidence for the HONOR Magic8 Pro in the device-qualification ledger. No app code is touched, no gate moves, and the device stays unsupported.

Technical Context

• The contributor ran the both-direction external write from a Shizuku shell. Both keys accept the value and HONOR's own battery screen follows in both directions, which excludes the read-only-mirror class the Oplus _status comparison pointed at and clears the _ui_-name suspicion on asw_ui_state. It closes only half of Blocker 1: step 2 of the protocol passes on the charging hardware moving, not the Settings UI, and the surviving failure mode is exactly oriole on LineageOS 20 (write accepted, the ROM's own controller reported the new config back, battery charged past the limit anyway).
• Records that Smart charge is adaptive rather than a cap, so it maps to Adaptive and offers no plateau for the hardware test to observe. That leaves Smart battery capacity as the only hardware-testable key here, and it is also the one carrying the level hazard.
• Sharpens that hazard three ways, because the existing paragraph understated it. The predicate is a disjunction (ChargeSessionService.kt:374), so BATTERY_STATUS_FULL alone trips it and guarding percent >= 100 would close nothing; full is the first branch of SessionDecisionEngine.decide, so the resulting RESTORE_FULL outranks every other outcome and is silent; nothing establishes that the broadcast rather than HONOR's display carries the synthetic 100, so the measurement has to read dumpsys battery; and no level clamp or cross-check exists anywhere to build a workaround on.
• Adds secure/charge_separation_all_scenarios_switch (bypass charging) as out-of-scope context, since ChargePolicy cannot express a bypass-only state, and notes the two follow-up asks: the direct device report for the codename the wizard omits, and pm list features / pm list packages -s for a MagicOS identity signal, because a property cannot answer it and the app has no way to probe one without a code change.
• Worth a close read: the sharpened hazard bullets make claims about live session code (ChargeSessionService, SessionDecision, StatsLimitHitDetector, ChargeAlarmEngine). Each cited line was checked against source, but they are assertions about behavior no supported device currently exhibits.

Refs #66