server/world: world-owned redstone engine

[HashimTheArab]

Credit to @cqdetdev for 90% of this, I cleaned it up, fixed bugs, and made it more consistent.

Why

The previous per-block redstone model (each block recomputes and re-propagates power itself via RedstoneUpdate/updateAround…, with a separate BFS for wire) was fine for the basic components dragonfly has today — wire, torch, lever, redstone block, note, TNT — but it wouldn't have scaled to the more complex ones (repeaters, comparators, pistons, observers):

• Non-deterministic, re-entrant evaluation. Updates fire in neighbour-notification order, blocks mutate the world mid-traversal, and positions get revisited many times per change. Order-dependent results and oscillations are easy to hit and hard to reproduce — and almost all non-trivial redstone is timing-sensitive.
• Power rules duplicated across Tx.RedstonePower, each Conductor, the wire BFS, and the individual blocks, with slightly different copies in each: weak vs. strong vs. conducted power, dust step up/down, "weakly powered block activates a mechanism but not dust", etc.
• Every component hand-rolls propagation. Adding repeater/comparator/piston/observer on the old model means N copies of ad-hoc neighbour-walking + cancellation + self-write plumbing, and the timing-critical bits (repeater delay/locking, observer pulses, comparator side inputs, piston BUD behaviour) really need a consistent per-tick evaluation order to match vanilla. You'd end up building this engine anyway, just later and with more to migrate.
• Cancellation was best-effort. HandleRedstoneUpdate(pos) got a bare position — no before/after/power context — and cancelling it didn't reliably stop downstream propagation.

This PR replaces that with a single world-owned engine that compiles a deterministic power graph once per tick and applies mutations through a cancellable HandleRedstoneUpdate(RedstoneUpdate) event — keeping the scope to the components that already exist, but making the complex ones a matter of implementing an interface rather than reinventing propagation.

What

A redstoneEngine owned by World that, once per tick, takes the set of changed positions, compiles a connected power graph (sources / relayers / consumers / actions), solves power across it (direct / strong / conducted, with per-edge signal loss through relayers), and applies the resulting block-state changes and side effects — each routed through HandleRedstoneUpdate(RedstoneUpdate), which can cancel both the mutation and its propagation.

Blocks no longer drive redstone; they declare capabilities:

• RedstonePowerSource / RedstoneStrongPowerSource / RedstoneWeakBlockPowerer — emits power.
• RedstonePowerRelayer (+ RedstonePowerRelayerNeighbourer) — carries power, defines its signal loss / topology (redstone dust).
• RedstonePowerConsumer (+ RedstonePowerPostUpdater) — block state follows input power (note block, doors, …).
• RedstonePowerAction / RedstonePowerContextAction — does something on a power edge (TNT priming).
• RedstoneNonConductive — solid block that doesn't conduct strong power (glowstone, TNT).

Tx.Redstone() exposes the engine within a transaction for scheduling re-evaluations, querying power, and managing transient redstone-torch burnout state.

Existing components migrated onto it:

• Redstone wire — relayer with explicit connection topology (horizontal connections, step up/down, glass vs. glowstone vertical transmission rules).
• Redstone torch — scheduled 1-redstone-tick inversion; burnout and recovery tracked by the engine over a rolling 60-tick window.
• Lever, redstone block — expose RedstonePower/RedstoneStrongPower; manual updateAround… calls removed.
• Note block — defers the note sound to a post-update hook so a cancelled update suppresses it; plays only on an uncancelled rising edge.
• TNT — rising-edge RedstonePowerAction; marked RedstoneNonConductive.
• Glowstone — marked RedstoneNonConductive; emits full light.

Removed: the old server/block/redstone.go BFS updater, server/world/redstone/state.go, and the world.Conductor / WeakBlockPowerer / RedstoneUpdater / old RedstonePowerRelayer interfaces.

World wiring: engine created with the world, ticked after neighbour updates, invalidated on block/liquid changes, and cleared on chunk unload; SetOpts.DisableRedstoneUpdates lets the engine apply its own writes without re-triggering itself. Also fixes a couple of scheduledTickQueue bookkeeping bugs where stale furthestTicks entries could block re-scheduling.

Benefits

• Deterministic — graph nodes and edges are sorted; the same circuit produces the same result every tick regardless of update arrival order. Far fewer ordering/oscillation bugs.
• One source of truth for power rules — weak/strong/conducted/relay logic, ClampRedstonePower, and RedstoneFullPowerConductor live in world instead of being re-implemented per block.
• Complex components become tractable — repeaters, comparators, pistons, observers fit as graph endpoints whose delayed/directional behaviour is expressed via scheduled ticks; they implement an interface or two and inherit graph membership, propagation, cancellation, and self-write suppression. No engine changes needed to add them.
• Real cancellation — HandleRedstoneUpdate carries the position, changed neighbour, source, before/after blocks, old/new power, tick, and cause; cancelling suppresses the mutation and downstream propagation.
• Cheaper churn — only changed regions are recompiled per tick instead of BFS fanning out from every neighbour notification.
• Regression-resistant — redstone is fragile to incidental changes elsewhere (block conductivity, face solidity, update ordering); this PR ships a broad wire/torch/lever/TNT/engine test suite so those breakages get caught instead of shipping.

Breaking changes

• world.Handler.HandleRedstoneUpdate(ctx, pos) → HandleRedstoneUpdate(ctx, RedstoneUpdate).
• Removed world.Conductor, world.WeakBlockPowerer, world.RedstoneUpdater, the old world.RedstonePowerRelayer, and Tx.RedstonePower(pos, face, accountForDust) — replaced by the capability interfaces above and Tx.Redstone().

Scope

Intentionally limited to the redstone components dragonfly already supports (wire, torch, lever, redstone block, note, TNT). Repeaters, comparators, pistons, observers, buttons, pressure plates, redstone lamps, etc. are left for follow-up feature PRs — the engine is built so those can be added as graph endpoints + scheduled ticks without reworking it.

Testing

New wire / torch / lever / redstone-block / TNT integration tests plus a long-wire-with-clocks benchmark.