feat(stovepipe): Track issues in bounded passes

stovepipe/controller/issuetrack/BUILD.bazel

@@ -6,8 +6,12 @@ go_library(
     importpath = "github.com/uber/submitqueue/stovepipe/controller/issuetrack",
     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",
@@ -18,11 +22,14 @@ go_library(
 go_test(
     name = "go_default_test",
     srcs = [
+        "delivery_test.go",
         "issuetrack_test.go",
         "planned_change_race_test.go",
     ],
     embed = [":go_default_library"],
     deps = [
+        "//platform/base/messagequeue:go_default_library",
+        "//platform/consumer/mock: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

@@ -1,5 +1,13 @@
 # Issue tracking
 
+## Notifications and bounded work
+
+Notifications identify a queue, build, and whether analysis is final. They share one queue partition and consumer group. A refreshing or finalizing pass is finished before another source is accepted. After a pass completes, request ingest order rejects older builds, finalized requests reject later refreshes, and completed owning notifications are ignored on replay. A notification that helps another pass finish holds once more for its own work.
+
+Each delivery processes at most 100 distinct task/unit keys, including a resumed change and closed records. Refresh opens newly reported issues but does not close by absence. Finalization also scans issue states: reported issues stay open or reopen, absent open issues close, and closed records remain untouched. A canceled build cannot close by absence because validation may not have run. Every scanned key advances progress, including closed records; a full read requires another batch to establish exhaustion.
+
+Before changing an issue, planning reads its current version and saves the cursor and intended transition together using progress CAS. No issue write happens if that save loses a race. With a planned change, the cursor identifies the issue to finish; without one, scans continue after the cursor. The planned change retains its original expected version and history timestamp. Final handoff requires successful complete detection and persistence, and the request's recorded winning terminal build. Finalization uses accumulated per-build issues, not just the latest detector response.
+
 ## Applying a planned change
 
 The controller applies one `PlannedIssueChange` already saved in the queue's progress record. The cursor identifies the issue; the change holds only its write details. Expected issue version zero means create-if-absent. A positive version means update that exact version. A retry never adopts a newly loaded version to execute old instructions.
@@ -10,4 +18,4 @@ A replacement must finish that same planned change before accepting later work.
 
 All writes use complete primary keys. There are no cross-record transactions, leases, snapshot indexes, or additional operation counters. Records and versions must not be deleted or reset while an old delivery could resume. All issue-state writers must follow this protocol.
 
-This layer does not scan build issues, receive queue messages, publish repairs, or register a runtime consumer. Planning, delivery orchestration, and terminal recovery are separate additions.
+The reference host does not register this consumer. Repair publication and terminal recovery remain follow-ups. Permanently failing planned changes block later issue-tracking work and require recovery; skipping the planned change is not safe. A future repair handoff must persist its prerequisites and publish before clearing the change that owns that obligation.