feat(stovepipe): Orchestrate issue checkpoints

Author: prathshenoy

stovepipe/controller/issuetrack/BUILD.bazel

@@ -7,9 +7,11 @@ go_library(
     visibility = ["//visibility:public"],
     deps = [
         "//platform/base/id:go_default_library",
+        "//platform/base/messagequeue:go_default_library",
         "//platform/consumer:go_default_library",
         "//platform/metrics:go_default_library",
         "//stovepipe/core/loader:go_default_library",
+        "//stovepipe/core/messagequeue:go_default_library",
         "//stovepipe/entity:go_default_library",
         "//stovepipe/extension/storage:go_default_library",
         "@com_github_uber_go_tally//:go_default_library",
@@ -19,9 +21,15 @@ go_library(
 
 go_test(
     name = "go_default_test",
-    srcs = ["issuetrack_test.go"],
+    srcs = [
+        "delivery_test.go",
+        "issuetrack_test.go",
+    ],
     embed = [":go_default_library"],
     deps = [
+        "//platform/base/messagequeue:go_default_library",
+        "//platform/consumer/mock:go_default_library",
+        "//platform/publish:go_default_library",
         "//stovepipe/core/messagequeue:go_default_library",
         "//stovepipe/entity:go_default_library",
         "//stovepipe/extension/storage:go_default_library",

stovepipe/controller/issuetrack/README.md

@@ -12,7 +12,13 @@ After all issue and history writes succeed, the controller saves the last fully
 
 Build issues added behind a refresh's cursor are picked up by a later refresh, which starts from the beginning. Before requesting finalization, the producer must successfully detect and persist the build's complete issue set. Finalization uses all issues accumulated for that build, not just the latest detector response.
 
-This layer does not receive messages, publish repair requests, register consumers, or implement recovery. Delivery orchestration is added separately. A future repair handoff must persist what the repair needs and publish before saving a cursor that would skip that work on retry.
+## Delivery orchestration
+
+Notifications carry a queue, build ID, and finalization flag. They must share a queue partition and consumer group. A delivery resumes pending work before admitting another source. When no pass is pending, request ingest order rejects older sources; an already-finalized request cannot accept more work. A completed owning notification is also ignored on replay.
+
+Every accepted pass saves its owning message ID and starts with an empty cursor. Each delivery applies one batch and saves the checkpoint. Pending passes hold for immediate redelivery. Completed passes acknowledge their owning message; a different notification that helped finish them holds once more so its own source can be considered. Source ordering is rechecked after conditional-write conflicts.
+
+This controller is not registered in the reference host. Repair publication and terminal recovery remain follow-ups. A future repair handoff must persist its prerequisites and publish before advancing the checkpoint past that obligation. Permanently failing pending work requires recovery before issue tracking can advance.
 
 ## Ownership prerequisite