fix: bound block-search volume so a large !searchForBlock can't stall the connection

[atiweb]

Problem

getNearestBlocksWhere (and getNearestBlocks, which wraps it) calls bot.findBlocks synchronously. findBlocks scans a volume that grows with the cube of maxDistance, and with the default count of 10000 it does not early-exit when the target block is rare or absent — it walks the entire volume on the main thread.

The !searchForBlock command exposes a search_range of up to 512 to the model. When the model asks for a large radius while looking for something that isn't nearby (diamonds, a specific log type, an ore vein), that synchronous scan blocks the Node event loop long enough that mineflayer can't answer keep-alive packets — and the server drops the bot mid-task. From the outside it looks like the bot randomly freezes or "crashes" during normal play.

Fix

Cap the search inside getNearestBlocksWhere:

• maxDistance → 128 — a search past the loaded view distance returns nothing useful anyway, so this doesn't drop real results.
• count → 4000 — a lower cap only makes findBlocks early-exit sooner; it can never return fewer results than a caller actually consumes.

…and lower !searchForBlock's search_range domain max from 512 to 128 to match, so the model can't request a radius the engine would only clamp.

Why it's safe

• findBlocks already only returns blocks within loaded chunks; beyond the view distance there is nothing to find, so capping the radius at 128 does not change results in practice.
• Capping count downward is strictly less work (it's an upper bound on matches collected). 4000 hits within a 128-block radius is far more than any current caller uses.

Scope

Two files, +14 / −3. No new dependencies; no behavior change other than the bound.