feat(stovepipe): reschedule process when concurrency gate is closed

[mnoah1]

What?

When the gate is closed (on first check or after losing a slot-claim race), the controller now re-enqueues the same ProcessRequest to the process topic via PublishAfter(GateWaitDelayMs) and acks the current delivery.

• The rescheduled message gets a fresh id ({request_id}/reschedule/{unix_ms}) rather than reusing the in-flight delivery's id: the message store dedupes on (topic, partition_key, id) and the original row is still present until the ack, so a same-id republish would be silently swallowed and then deleted by the ack — permanently stranding the queue head.
• GateWaitDelayMs must be configured positive; a zero/negative value returns an error (with a config_errors counter) rather than silently publishing with no delay. Publish failures emit publish_errors and surface the raw error so the consumer's classifier decides retryability. The controller now takes the TopicRegistry for publishing, wired through in the stovepipe server main.

Why?

Implementing proposed PublishAfter behavior from RFC: https://github.com/roychying/submitqueue/blob/chenghan.ying/stovepipe-build/buildsignal-doc/doc/rfc/stovepipe/steps/process.md#option-2-ack-and-publishafter

This allows us to reschedule the delivery for later processing, rather than having publish pause the goroutine to wait for the gate to open.

Test Plan

• make local-stovepipe-start
• First ingest: grpcurl -plaintext -d '{"queue":"monorepo/main"}' localhost:32784 uber.submitqueue.stovepipe.Stovepipe/Ingest
• Manually clear from DB, but leave the build slot claimed: DELETE FROM request_uri WHERE queue='monorepo/main';
• Ingest again: grpcurl -plaintext -d '{"queue":"monorepo/main"}' localhost:32784 uber.submitqueue.stovepipe.Stovepipe/Ingest
• Log: "rescheduled latest head awaiting build slot" request_id=request/monorepo/main/2 in_flight_count=1 delay_ms=5000 - appears every 5 seconds

[behinddwalls]

⚠️ Automatic stack rebase failed

This PR could not be automatically rebased after its base PR was merged. The rebase hit conflicts that need manual resolution.

To fix manually:

git fetch origin
git checkout mnoah1/stovepipe-process-gate-defer
git rebase --onto origin/main 75abca64a764251e8cd57316ebd6731ca24390b1 mnoah1/stovepipe-process-gate-defer
# resolve conflicts, then:
git push --force-with-lease

Then update this PR's base branch:

gh pr edit 338 --base main

[mnoah1]

Alternative considered: add a value on the payload that keeps track of reschedules. I think timestamp provides sufficient uniqueness here for now but we could consider that option as well.