fix: drop chrome.alarms permission (0.0.30 release)

[BitHighlander]

Why

Chrome Web Store update gates on permission additions — `alarms` was added in #55 to keep the 45s post-broadcast drop-check firing across MV3 service-worker idle eviction. The drop-check is diagnostic UX, not load-bearing for tx safety:

• 8s check still uses `setTimeout` (< 30s — always fires while SW is warm from broadcast)
• 45s check fires during active dApp interaction (block polling / eth_chainId pings keep SW alive)
• When the SW idles immediately after broadcast, we just miss the 45s warning. The tx outcome is unchanged.

Trading a rare diagnostic warning for not gating Chrome Web Store rollout on user re-consent.

What's removed

• `alarms` permission from `chrome-extension/manifest.js`
• `chrome.alarms.create` call in `scheduleDropCheck`
• `chrome.alarms.onAlarm` listener registered at module load
• `DROP_CHECK_ALARM_PREFIX` constant + name-encoded delay parsing

`scheduleDropCheck` becomes a one-liner: `setTimeout(performDropCheck, delayMs)`.

Version

Bumps to 0.0.30 (since 0.0.29 merge already landed on master). This is the version that ships to the Web Store.

Files

• `chrome-extension/manifest.js`
• `chrome-extension/src/background/chains/ethereumHandler.ts`
• 20 × `package.json` version bumps via `make bump VERSION=0.0.30`

Test plan

• Build clean
• `dist/manifest.json` permissions field no longer contains `alarms`
• Trigger a tx broadcast; verify `[DROP-CHECK]` line still logs at 8s
• During active dApp use (Uniswap polling), verify 45s check still fires (SW kept warm)

🤖 Generated with Claude Code