bias = hop * step + hop^2 * BOT_HOP_GROW_MILLIS
Bumps hop_step 3000->2000, adds BOT_HOP_GROW_MILLIS=400, raises cap
15000->50000 and TTL 75000->95000. Forces re-default of hop_step on
existing bots via BOT_PREFS_VERSION 5->6.
Gap between adjacent hops now grows with hop count (3200ms at hop 1
all the way to 8000ms at hop 8), so a far bot reliably has time to
hear a near bot's reply through the mesh before its own scheduled
fire time -- previous linear bias kept the gap constant at 3000ms,
which wasn't enough at 6+ hops where reply propagation takes ~5-10s.
Shortens BOT_PREFS_INITIAL_FLOOD_ADVERT_MILLIS from 120000 to 5000 so
the bot announces itself to the whole mesh ~5s after boot instead of
2 minutes after boot. Recurring flood interval still 24h (upstream
default); ask if you want that tightened.
Bumps base/jitter/hop_step/cap/TTL ~25% for more reliable token
suppression at the multi-hop edge. Bumps BOT_PREFS_VERSION 4 -> 5 to
force re-default of hop_step_ms on existing bots. Test bumped
many_hops.path_hash_count 10 -> 20 so the cap-check still trips with
the new 15000ms cap.
- BOT_HOP_STEP_MILLIS_DEFAULT 1500 -> 2500
- BOT_HOP_BIAS_MAX_MILLIS 8000 -> 12000
- BOT_RESPONSE_PENDING_TTL_MILLIS 45000 -> 60000
- BOT_PREFS_VERSION 3 -> 4 (forces re-default of hop_step_ms on existing
bots that saved the old 1500 value)
- writeAckResponse + executeTest: drop the literal "ack " prefix so test
responses now start with "@[sender] ..."
Field test showed two bots with token-matching `[1865]` responses both
firing because the far bot scheduled its reply before the near bot's
reply could propagate back through the mesh. New hop step gives ~5-8 s
of margin at the 4-hop boundary.
