[prathshenoy]

Summary

What:

• Notify issue tracking after build analysis saves its detected issues, including when a completed build reports none.
• Send updates in queue order and wait for the request’s chosen build before requesting finalization, without enabling the consumer.

Why:

• Notify issue tracking when build analysis has saved failures that need to affect current issue state. Saving failures under a build does not open or close issues by itself. A successful final analysis must send a notification even when it finds no failures, so issues left open by earlier builds can still be closed.
• Avoid finalizing issue state from the wrong build or before its failures have been saved. Build completion can be visible before the request records which build supplied its result, so final notification waits for that decision. Failed publication is retried rather than silently losing the update, while issue analysis remains independent of the recorded validation outcome.

Test Plan

• Add unit tests.

Revert Plan

• Revert this PR. No issue-tracking consumer is enabled and no schema changes are introduced; previously published notifications can remain unused.

Issue Links

• CODEM-607

Stack

1. feat(stovepipe): Retain versioned issue state #942
2. feat(stovepipe): Save planned issue changes #943
3. feat(stovepipe): Apply planned issue changes #932
4. feat(stovepipe): Track issues in bounded passes #940
5. feat(stovepipe): Publish issue-tracking updates #939