Fix keeper boot crash, wire profitability gate, add reputation signals, fix ZK worker pool crash (#780, #781, #784, #791)

[thelux134]

Important bug found and fixed first

keeper/index.js had two separate "initialize execution queue" blocks — const queue = ... declared twice in the same function scope. This is a hard SyntaxError ("Identifier 'queue' has already been declared"); the keeper cannot start at all in its current state on main, not even --dry-run. Verified with node --check keeper/index.js before and after. Removed the second, incomplete duplicate (missing the retryScheduler wiring the first one has). This looks like a leftover from a merge conflict — the repo has several conflicts_*.txt/merge_output_*.txt files checked in at the root from past merges.

Also found, not fixed (out of scope, flagged for follow-up): keeper/src/xdrErrorDecoder.js fails node --check with a garbled/mojibake identifier — genuine file corruption. It's not required anywhere else in the keeper, so it doesn't block boot, but it can't be required either.

Summary

• 🤖 [KEEPER] High-Performance Webhook Trigger Protocol with Signature Verification #780 (webhook trigger): already fully implemented and wired end-to-end — WebhookAuthProtocol (HMAC-SHA256, timestamp tolerance, in-memory and Redis-backed replay protection), WebhookTriggerHandler, and live routing through the metrics server's HTTP listener. Nothing to fix; added docs/webhook-trigger.md since none existed.
• 🤖 [KEEPER] Automated Fee Arbitrage & Profitability Maximization Engine #781 (profitability): ProfitabilityEstimator and GasForecaster already existed but neither was imported anywhere outside their own files. Wired both into keeper/index.js: GasForecaster.recordExecution() runs after every successful execution to build per-task fee history; a new pre-execution gate (config-flagged, default OFF via PROFITABILITY_GATE_ENABLED since this changes existing execution behavior) only skips a task when the forecaster has 'high' confidence its bounty won't cover the forecasted cost, deferring to normal execution whenever there's insufficient history.
• 🤖 [KEEPER] Historical Performance Telemetry and Keeper Reputation Scoring System #784 (reputation): KeeperReputationScorer already existed and was already wired to a live endpoint, but scored nothing for "execution speed" or "gas efficiency". Added durationMs/bounty tracking through to history.js's getExecutionSummary(), and two new weighted signals in scoreKeeper() (both default to neutral 1.0 when a keeper has no history yet). Verified against the existing insights.test.js assertion (score still > 70 with the same inputs, after rebalancing weights).
• 🛡️ [ZK-SERVICE] Distributed Worker Node Pool with Task Load Balancing #791 (ZK worker pool): a real worker_threads pool already existed (spawn, crash-replace, memory limits, timeout, proof caching) — but generateProof() called this._acquireWorker(), which was never defined. Every /generate-proof request threw a TypeError at runtime — confirmed by index.test.js's existing 'should generate ZK proof successfully' test, which already exercises this path and would be failing on main. Added _acquireWorker() and removed a block of dead/unreachable code after an existing return proofPromise statement. Not fixed (separate, out of scope): lib/proof-worker.js still returns a hardcoded mock proof rather than invoking the real Halo2/circom logic in lib/halo2-adapter.js.

Test plan

• node --check on every changed file, before and after, to catch both the pre-existing crash and confirm no new syntax errors
• Full node --check sweep of keeper/src/*.js and zk-proof-service/lib/*.js to look for further corruption from the same merge history (found only xdrErrorDecoder.js, flagged above)
• Hand-traced index.test.js's existing ZK proof generation test against the _acquireWorker fix to confirm it now exercises the real, working path
• Hand-computed insights.test.js's existing reputation-score assertion against the rebalanced weights to confirm it still passes

Closes #780
Closes #781
Closes #784
Closes #791

[drips-wave]

@thelux134 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[vercel]

@thelux134 is attempting to deploy a commit to the Ayomide Adeniran's projects Team on Vercel.

A member of the Team first needs to authorize it.

[ayomideadeniran]

Pr under review