Fix orphaned webhooks, leader reentry, airdrop linking, and WS subscription cap

[oldtaker24]

Fixes #113, Fixes #119, Fixes #122, Fixes #124

What changed

• Removed dead services/webhooks.js and its test; updated README webhook events table to clarify which events have active dispatch paths (services/webhooks.js + services/webhook.js are an entirely orphaned, never-wired parallel webhook delivery implementation #113)
• Captured leaderElection originals at construction and restore on stop so repeated start/stop cycles don't cumulatively monkey-patch (leaderAwareJob.start()/stop() is not reentrant — repeated cycles permanently and cumulatively monkey-patch the shared leaderElection instance #119)
• Added contract_airdrop_id field to airdrop records for on-chain linking; documented that REST-created airdrops are off-chain bookkeeping only (REST-managed airdrops and indexer-observed on-chain airdrops use disjoint ID namespaces with no linking field — on-chain claim status never reaches the REST API #122)
• Enforced MAX_ASSETS_PER_CLIENT against cumulative client.assets.size instead of per-message; send error when cap is hit (PriceSubscriptionManager's MAX_ASSETS_PER_CLIENT cap is enforced per-message, not cumulatively — repeated subscribe calls bypass the limit #124)

Why

• services/webhooks.js was a fully orphaned parallel webhook system never wired to any route, confusing contributors and creating dual-signing-scheme risk
• leaderAwareJob.start() monkey-patched leaderElection methods without restoring them in stop(), causing wrapper accumulation on repeated cycles
• REST-created airdrops had no linking field to correlate with indexer-observed on-chain state, leaving two disjoint views of the same entity
• WebSocket subscription cap was enforced per-message only, allowing unbounded cumulative growth via repeated subscribe calls

How to test

• services/webhooks.js + services/webhook.js are an entirely orphaned, never-wired parallel webhook delivery implementation #113: grep -r "services/webhooks'" src/ test/ returns no results
• leaderAwareJob.start()/stop() is not reentrant — repeated cycles permanently and cumulatively monkey-patch the shared leaderElection instance #119: Start/stop a wrapped job 3+ times, verify no callback duplication per tryAcquire/renew
• REST-managed airdrops and indexer-observed on-chain airdrops use disjoint ID namespaces with no linking field — on-chain claim status never reaches the REST API #122: Create airdrop, PATCH with contract_airdrop_id, verify field persists
• PriceSubscriptionManager's MAX_ASSETS_PER_CLIENT cap is enforced per-message, not cumulatively — repeated subscribe calls bypass the limit #124: Send 10 subscribe messages with 5 assets each, verify client.assets.size never exceeds 5 and error is returned when cap hit

[drips-wave]

@oldtaker24 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