route cluster ttl cleanup through the replicated delete path

[fabracht]

Summary

Cluster-mode companion to the agent TTL fix (#132). The cluster TTL sweep removed expired rows with a raw in-memory entities.remove:

• it never released the row's unique-constraint guards, so an expired unique value became permanently unclaimable
• it emitted no change event, so watchers and cross-node subscribers never learned of the deletion
• it did not replicate — each node independently mutated its own copy

The sweep now reaps each expired row this node is the data-partition primary for through the same path as a normal delete (execute_json_delete → db_delete_prepare + db_commit + release_unique_for_deleted_record + change event + resource-grant clearing), so the delete releases guards, emits a change event, and replicates to the replicas. Non-primary nodes skip; the primary's replicated delete reaches them. It runs under the controller write lock, so the scan and the deletes are atomic with respect to other controller messages (no renewal can interleave). The store's scan+raw-remove cleanup_expired_ttl is replaced by a scan-only scan_expired_ttl.

FK cascade on TTL expiry remains a follow-up (holds are leaf entities) — same deferral as the agent side (docs/design/hold-reclaim.md).

Test plan

• cargo test -p mqdb-cluster --all-features (new: ttl_reap_releases_unique_claim_and_removes_row, ttl_reap_leaves_unexpired_row)
• cargo clippy --all-targets --all-features -- -D warnings