Diagnostics: Probe the Oplus charge keys and make probe results tri-state

[d4rken]

What changed

Device-support reports now say something useful about Oppo, OnePlus, and Realme phones that aren't on ColorOS 15, and they no longer claim a setting is missing when the system simply refused to let Amply look.

A report from an Oppo F11 Pro (ColorOS 11) arrived carrying nothing at all about charge protection. Amply recognised it as an Oplus device, then checked only Samsung's, GrapheneOS's, and LineageOS's settings, never the ColorOS ones it already knows about. Reports from those devices now include whether each of the two ColorOS charge-protection settings is there.

Separately, every one of these presence checks reported "not present" both when a setting genuinely didn't exist and when Android refused the read. Those are very different answers, and conflating them already produced a wrong conclusion: a GrapheneOS report said the charge limit was missing while that phone was actively holding at 80%. Reports now distinguish present, absent, and read refused.

No change to which devices Amply can control, and no new permissions. Only setting presence is reported, never any value.

One extra ColorOS setting is now recognised as safe to disclose automatically in the "Help add support" wizard, so a contribution from an Oplus device no longer arrives with half of a paired feature hidden behind a manual reveal.

Technical Context

• Root cause of the empty report: the live Oplus gate keys on ro.build.version.oplusrom, which doesn't exist on pre-rebrand ColorOS, so it was the report's only Oplus signal and it read none. Absence was also indistinguishable from an SELinux-denied read, since SystemPropertyReader returns "" on denial.
• OplusKeyProbes lives on the reporter's IO path rather than in DeviceInfo, deliberately. DeviceInfo.current() is rebuilt on every dashboard refresh from the main thread by ChargingRepository, MainActivity, and the wizard VM; these two probes gate nothing, so putting them in the shared snapshot would pay two synchronous binder calls per refresh for diagnostics-only data.
• Worth close review: hasProtectBattery gates device-wide Samsung writes and both flags feed hasSupportLead. They survive as derived == PRESENT accessors specifically so a refused read still fails closed exactly as the old booleans did. Codex reviewed this point directly and confirmed no gate widened; the assertion is pinned in DeviceInfoTest.
• ABSENT is documented as "nothing found", not a proven negative. A fourth READ_FAILED state was considered and rejected: the platform swallows provider-acquisition and RemoteException failures internally and returns null, so such a state would be false precision.
• Report schema 9 → 10 (two fields renamed with new semantics, two added). Nothing in the repo parses the report format; the two remaining old-name mentions are historical prose describing an actual schema-9 report and are correct as-is.
• The smart_charge_protection_switch_state allowlist gap was independent of the adapter, which already handled both keys. SettingWritePolicy had both; only the disclosure allowlist was missing one.
• The four deleted CANDIDATE_KEYS sets had no references in main or test.