deleteKey succeeds (statusCode 100) but expired Keypad passcodes are never removed from keyList #498

# Nightly cleanup job, run 1 (2026年07月20日 22:37 UTC)
# For each expired passcode we send deleteKey and check the response statusCode.
delete stale key deviceId=DEVICE_A keyId=14 name=<redacted> status=expired createTime=2026年04月17日T08:50:12.000Z
delete stale key deviceId=DEVICE_A keyId=15 name=<redacted> status=expired createTime=2026年04月25日T04:29:56.000Z
delete stale key deviceId=DEVICE_A keyId=16 name=<redacted> status=expired createTime=2026年05月09日T07:01:59.000Z
delete stale key deviceId=DEVICE_A keyId=17 name=<redacted> status=expired createTime=2026年05月09日T08:10:35.000Z
delete stale key deviceId=DEVICE_A keyId=18 name=<redacted> status=expired createTime=2026年05月28日T00:16:12.000Z
... (151 delete commands in total, every one returned statusCode: 100, zero errors)
summary run 1: account=ACCOUNT_1 candidates=102 deleted=50 failed=0 remaining=52
summary run 1: account=ACCOUNT_2 candidates=70 deleted=50 failed=0 remaining=20
summary run 1: account=ACCOUNT_3 candidates=164 deleted=50 failed=0 remaining=114
# Nightly cleanup job, run 2 (2026年07月21日 19:30 UTC, ~21 hours later)
# The SAME key ids are still present in keyList and are selected again.
delete stale key deviceId=DEVICE_A keyId=14 name=<redacted> status=expired createTime=2026年04月17日T08:50:12.000Z
delete stale key deviceId=DEVICE_A keyId=15 name=<redacted> status=expired createTime=2026年04月25日T04:29:56.000Z
delete stale key deviceId=DEVICE_A keyId=16 name=<redacted> status=expired createTime=2026年05月09日T07:01:59.000Z
delete stale key deviceId=DEVICE_A keyId=17 name=<redacted> status=expired createTime=2026年05月09日T08:10:35.000Z
delete stale key deviceId=DEVICE_A keyId=18 name=<redacted> status=expired createTime=2026年05月28日T00:16:12.000Z
... (150 delete commands in total, every one returned statusCode: 100, zero errors)
summary run 2: account=ACCOUNT_1 candidates=102 deleted=50 failed=0 remaining=52
summary run 2: account=ACCOUNT_2 candidates=70 deleted=50 failed=0 remaining=20
summary run 2: account=ACCOUNT_3 candidates=157 deleted=50 failed=0 remaining=107
# 149 of the 150 key ids deleted in run 2 were identical to those already
# "successfully" deleted in run 1.
# For ACCOUNT_1 and ACCOUNT_2 the candidate count did not change at all.
# Snapshot of GET /v1.1/devices keyList for one device (before run 1)
device=DEVICE_B total_keys=64 status_counts={"expired":63,"normal":1} oldest_createTime=2023年03月29日T04:03:26.000Z
device=DEVICE_C total_keys=56 status_counts={"expired":52,"normal":4} oldest_createTime=2023年03月07日T10:25:07.000Z
device=DEVICE_D total_keys=48 status_counts={"expired":42,"normal":6} oldest_createTime=2026年04月13日T02:23:23.000Z
# Note: our logs record only the response statusCode (we treat statusCode != 100
# as a failure). Full response bodies were not retained. We can add full-body
# logging and provide it if needed.

We call the Open API directly; there is no config file. The exact requests are:
# 1. Fetch device list (including keyList)
GET https://api.switch-bot.com/v1.1/devices
Headers:
 Authorization: <token> # redacted
 sign: <HMAC-SHA256> # redacted
 t: <epoch millis>
 nonce: <random string>
 Content-Type: application/json
# 2. Delete one expired passcode
POST https://api.switch-bot.com/v1.1/devices/{deviceId}/commands
Headers: (same as above)
Body:
{
 "commandType": "command",
 "command": "deleteKey",
 "parameter": {
 "id": "14"
 }
}
Response we receive:
{
 "statusCode": 100,
 "message": "success",
 "body": {}
}
The `id` value is taken directly from `body.deviceList[].keyList[].id` of the
`GET /v1.1/devices` response, converted to a string.
Question: is `parameter` supposed to contain any field other than `id`
(e.g. `name` or `type`)? The documentation does not make this clear, and since
the API returns statusCode 100 we have no signal that anything is wrong.