fix: notify lighthouse from backfill loop when new subgraph data is found

[otsybizov]

🤖 Linear

Closes CONG-XXX

[Copilot]

Pull request overview

This PR updates Cartographer’s backfill maintenance cycle to notify Lighthouse queues when backfill operations pull new subgraph data, enabling Lighthouse to process newly discovered work without waiting for webhooks.

Changes:

• Add Lighthouse queue notification logic to the handler backfill loop, including notification deduplication.
• Update several cartographer-core backfill operations to return a count of newly found/saved records to drive conditional notifications.
• Add a dedicated handler test suite for backfill behavior (operation execution, notification triggers, deduping, and failure isolation).

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
packages/agents/cartographer/handler/src/maintenance/backfill.ts	Splits operations into notifying vs non-notifying groups, collects queues to notify, and triggers Lighthouse notifications.
packages/agents/cartographer/handler/src/mockable.ts	Introduces a handler-local re-export layer so core ops can be stubbed in handler unit tests.
packages/agents/cartographer/handler/test/maintenance/backfill.spec.ts	Adds unit tests validating operation execution, notification behavior, deduplication, and resilience on failures.
packages/agents/cartographer/core/src/operations/monitor.ts	Changes updateMessages to return a count of new messages processed.
packages/agents/cartographer/core/src/operations/invoices.ts	Changes hub invoice/deposit update operations to return counts (and consistently return 0 on early exits).
packages/agents/cartographer/core/src/operations/intents.ts	Changes intent-related update operations to return counts to support notification decisions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

updateMessages is treated as a single boolean signal, but here any non-zero count triggers SETTLEMENT + FILL + SOLANA notifications. Since updateMessages can return >0 for spoke Intent/Fill messages (and non-Solana hub messages), this can enqueue unnecessary settlement/solana work. Consider returning more granular info from updateMessages (e.g., counts per message type / per queue or a Set of queues to notify), or splitting hub vs spoke message updates so backfill only notifies the queues that actually had new relevant data (similar to processHubMessage / processSpokeMessage notification behavior).

[Copilot]

This file calls restore() in afterEach, but the handler test suite already runs a global afterEach hook that calls sinon.restore()/sinon.reset() (test/globalTestHook.ts). The extra restore is redundant and can be removed here (and then the restore import can be dropped).