feat(alerts): let a consumer record its own deliveries

[Vishnuujain]

Problem

A consumer that doesn't poll change events can't report what it delivered.

AbstractEventConsumer updates AlertMetrics only on its own poll-and-publish path, and commits only when the offset moved. A subclass that computes its own work has neither, so its alert reports zero events sent on the subscription status and diagnostics endpoints no matter how much it actually delivered.

What this adds

• protected recordDelivery(int successCount, int failedCount) so a subclass can report what it sent.
• Commit when the metrics moved, not only when the offset moved. Otherwise the counters are updated in memory and dropped.
• The finally body moves into persistTick, now that there are two reasons to commit. Gap state still persists only when no commit happened.

Existing consumers are unaffected: nothing calls recordDelivery, so the new flag is false on every path they take.

Tests

3 new in AbstractEventConsumerTest, 33 pass in the class. Each new test was checked to fail without the fix.

Used by https://github.com/open-metadata/openmetadata-collate/pull/6141

🤖 Generated with Claude Code

[github-actions]

❌ PR checklist incomplete

This PR cannot be merged until the following are addressed on its linked issue:

• No GitHub issue is linked. Link an issue in the Development section of the PR (or add Fixes #12345 to the description). For a same-org cross-repo issue, add Fixes open-metadata/<repo>#123 to the description.

The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically.

Maintainers can bypass this check by adding the skip-pr-checks label.

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ingestion'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[manerow]

Looks good to me.

What I checked:

• recordDelivery and recordFailure only affect a consumer that calls them, and no existing consumer does, so the commit flag stays false on every path they take today.
• Committing when the metrics moved, not only when the offset moved, is what makes a self-delivering consumer's counters reach the subscription at all, and the gap-state branch still only runs when no commit happened.
• A failure row written with no change event is accepted by consumers_dlq, whose generated NOT NULL column reads the top level timestamp that recordFailure sets, and the row is keyed per subscription so repeated failures replace rather than accumulate.
• extractTimestamp was the one reader that assumed a change event is always present, and it now falls back to the failure's own timestamp.

One note on sequencing: the Collate side (collate#6141) doesn't call these hooks yet, so its alert still reports zero events sent. Worth wiring up there once this merges, otherwise the gap this PR opens stays unused.