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.