The charger's own card list gets a door, and says where it differs

0104 was already implemented and already in the action catalogue; nothing
routed to it, so the only way to see the device's list was as a side
effect of writing a card. It has an endpoint now, and the panel a button.

The two lists are compared where they meet: a card the charger holds and
the account has forgotten still opens it, and a card only the account
holds will not, and neither shows anywhere else. The comparison is drawn
only when they disagree, and the device's reading is dropped on a refresh
rather than measured against an account list from a later moment.

The new test asks all four card routes without a token: a capability the
plugin implements and the catalogue advertises is still unusable if
nothing routes to it, and no other test here would notice.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Web App/web/src/api.js

@@ -357,6 +357,12 @@ export const api = {
       `/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/rfid-cards/${encodeURIComponent(cardNumber)}`,
       { method: "DELETE" }
     ),
+  // The list the charger itself holds, asked of the device rather than of the
+  // account. Both are written by every add and remove, and they can still come
+  // apart; this is the only call that says so. Answers with {cards} — bare
+  // numbers, because the device has no field for a card's name.
+  getAnkerChargerCards: (sn) =>
+    request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/rfid-cards/charger`),
 
   // Anker Solix control (per charger), over whichever transport the user's
   // control mode selects. getAnkerControl returns the control mode, connection