Charging: Scope the GrapheneOS replug-latch claim to its qualifying device

[d4rken]

What changed

No user-facing behavior change. This updates the device-qualification ledger and the repo's enabled-plugin list.

The ledger recorded that on GrapheneOS an externally written charge-limit value is reliably picked up at the next plug session. That was proven on one device and written as though it held for the ROM generally. A second device refutes it, so the claim is now scoped to the device and build it was actually proven on, and the refutation is recorded as a known gap.

Technical Context

• Root observation (issue [Device Support] GrapheneOS (Pixel 9 Pro XL) #49, comment 5414184320): on a Pixel 10 running GrapheneOS 2026081301, a bare settings put global battery_charge_limit 0 made while unplugged, and confirmed off in the ROM's own Settings UI, was still ignored at the next plug-in. The device held at exactly 80%. Amply was out of the loop for that test and its package appears nowhere in the 52k-line capture, so this is not an app-side failure. The same device's native Settings toggle works normally, which is what isolates it to the external-write channel.
• Cause is deliberately left undetermined. The first device was qualified on build 2026080501 and the second observed on 2026081301, and neither was tested on the other's build, so a ROM release change and a Pixel 10 generation difference fit the evidence equally. Naming a cause here would be a guess that the ledger is later trusted on.
• The gap entry records blast radius, not just the symptom: every write on this adapter shares one code path, so on a device behaving this way the persistent policy writes, session restore, and boot recovery are all hardware-level no-ops that read back as verified. Boot recovery's convergence check returns early for the same reason, since a matching settings readback is treated as convergence.
• The protective direction (writing the limit on) has never been run by anyone. If it is ignored too, the app would claim protection that is not enforced, which is materially worse than the observed failure. The entry marks that as a hold on widening or re-qualifying anything on this ROM, and it is asked of the reporter in the issue.
• The second GrapheneOS ledger row (the Pixel 10 one) needed no correction; it already stated that it adds no enforcement evidence. One evidence caveat is recorded in the entry: the capture carries no settings-provider logging, so the setting's value at plug time rests on the reporter's statement plus the ROM's UI rather than on instrumentation.

The plugin-list commit is unrelated housekeeping carried along at the maintainer's request: it renames the support-investigator entry to support following the plugin's own rename, and enables frontend-design.