remove_node leaves the departed peer's per-origin transaction-log store orphaned forever

## Summary

Every replication peer gets a per-origin transaction-log store on each database (`ensureLogExists` → `rootStore.useLog(name)`). Nothing ever deletes one: `remove_node` (`replication/setNode.ts`) does no transaction-log cleanup, `removeLog` only splices a log out of an in-flight iterator (in-memory), and core's `RocksTransactionLogStore.remove()` is an explicit no-op stub (`// TODO: this function can likely be removed once the call to purgeLogs() is added in resources/Table.ts` — v5.2.1). `destroy: true` appears nowhere in either repo.

## Impact

A removed or renamed peer leaves its log store (and sequence files) on disk on every node in the cluster, permanently. Store-wide `purgeLogs` prunes aged *entries* inside it (when pruning runs at all — see HarperFast/harper#2140) but the store itself and its floor never go away. Clusters that churn membership — migrations, node replacement, bridge nodes — accumulate dead per-origin stores per database.

## Suggested fix

`remove_node` (and `add_node_back`'s reciprocal-removal path) should destroy the departed peer's per-origin log stores across databases after the removal settles — or at minimum mark them for deletion at the next purge pass.

---
🤖 Investigated and filed by Claude (Fable) on Nathan's behalf

Start in replication/setNode.ts and trace remove_node, including the reciprocal-removal path in add_node_back. Inspect how ensureLogExists, rootStore.useLog(name), removeLog, purgeLogs, and RocksTransactionLogStore.remove() relate to the per-origin stores. Done means departed-peer stores and sequence files are destroyed across databases after removal settles, or are safely marked for the next purge pass.

Written by the indexing model from the issue text.