Safe zone and trigger zone overlap when bandCount < 7

[TaprootFreak]

Bug

BandManager.isInSafeZone() and BandManager.getTriggerDirection() produce overlapping classifications when bands.length !== 7, and onPriceUpdate consults safe-zone first — so trigger zones get silently absorbed.

Reproduction

With 5 bands (current DEV state, see #76):

// src/core/band-manager.ts:42
isInSafeZone(idx)  // count=5 → safeStart=1, safeEnd=3 → indices 1, 2, 3 are "safe"

// src/core/band-manager.ts:53
getTriggerDirection(idx)  // idx<=1 → 'lower', idx>=N-2=3 → 'upper'

Index 1 is both safe and lower-trigger. Same for index 3 (safe + upper-trigger). Since onPriceUpdate (rebalance-engine.ts:337) returns on safe-zone before checking trigger, the trigger never fires.

Concrete impact

DEV pool right now: currentTick=-112302 is in band index 1 (the lower trigger band in a 7-band model). The bot reports state: MONITORING and does nothing. Pool price has drifted ~0.4% below CoinGecko reference. Without a corrective rebalance, the price will continue to drift downward inside band 1 indefinitely.

Proposed fix

Either:

1. Tie safe/trigger boundaries explicitly to MIN_OPERATIONAL_BANDS so they remain non-overlapping and trigger-first, or
2. Raise MIN_OPERATIONAL_BANDS to 7 (or whatever calculateBands produced at start) and emergency-stop earlier — accepting that <7 bands is a degenerate state that should not be operated through.

Option 2 is simpler and matches the README's 7-band invariant. Option 1 preserves operation but needs care: with 5 bands there is no "buffer" zone left, so the bot would lose its safety against fast price moves between polls.

Severity

P1 — silent failure mode, no notification, can hide depeg/drift indefinitely.