Silently dropped task ids when the task hash is missing in acquire.lua and mover.lua

Split out of #48 during the fair multi-queue scheduling change (codingjoe-fair-multi-queue-scheduling).

defer: Silent task loss when a ready/deferred set member's task hash is gone (acquire.lua drops the id, mover.lua drops a due id whose score is gone) with no result row written. Separate durability bug; the sets have no TTL. [threadmill/backends/lua/acquire.lua, threadmill/backends/lua/mover.lua]

Problem

ZPOPMIN removes the member before the data hash is read, so when HGET returns nothing (hash gone, or cjson.decode fails) the loop moves on and the task id is left nowhere: not in the ready set, not in the running set, and no result row is written.

mover.lua has the same shape: it drops a due id from the deferred set when HGET score returns nothing, again without a result row.

The ready and deferred sets have no TTL, while the task hash expires after lease_ttl * 3 + result_ttl (27 h with the defaults), so a backlog or a worker outage longer than that silently loses tasks instead of failing them. That conflicts with the project's Durability and Consistency design principles.

Open questions

• Should the expired hash be reported as a FAILED result (with what payload, given the data is gone), or should the ready/deferred sets be bounded or refreshed instead?
• Is a synthetic result row even deserializable by peek() and the inspector, which expect a serialized TaskResult?

QED

1. Enqueue a task.
2. Delete its hash key ({prefix}:task:{id}) while it stays in the ready set.
3. acquire() — the id vanishes with no trace.

Commencez par lire threadmill/backends/lua/acquire.lua et threadmill/backends/lua/mover.lua, puis reproduisez le cas QED en supprimant un hash de tâche alors que son ID reste dans la file d’attente. Examinez comment les lignes de résultat sont sérialisées et consommées par peek() et l’inspecteur. L’issue n’est terminée qu’une fois la stratégie en cas d’échec décidée, que les IDs de tâche ne sont plus perdus silencieusement et que la couverture de régression vérifie le comportement choisi.