feat(stovepipe): admit latest head to build

[mnoah1]

What?

This PR adds in handling to admit a request to a build:

• admitRequestToBuild handles requests that are ready to be have a build enqueued: when a build slot is available and a request matches the queue's current latest request, the request will now hit this branch
• admitRequestToBuild performs two actions: claim a build slot by incrementing the queue's in-flight builds, and transition the request to processing

This leaves 3 main codepaths to fill out the rest of the initial implementation for the process step (marked with TODO):

• Strategy selection logic ("full" placeholder currently)
• Re-enqueue requests when no build slot is available
• Publish the actual build step

Why?

Continuing to implement the process step outlined in process.md.

Test Plan

1. make local-stovepipe-start
2. grpcurl -plaintext -d '{"queue":"monorepo/main"}' localhost:32773 uber.submitqueue.stovepipe.Stovepipe/Ingest

admitted request to build line below:

stovepipe-service-1  | 2026-07-13T15:41:15.769Z	DEBUG	queue_mysql.message_store	mysql/message_store.go:217	fetched messages	{"topic": "process", "partition_key": "monorepo/main", "count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.773Z	DEBUG	consumer/consumer.go:351	processing delivery	{"controller": "process", "topic_key": "process", "message_id": "request/monorepo/main/1", "partition_key": "monorepo/main", "attempt": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.781Z	INFO	process_controller	process/process.go:189	admitted request to build	{"request_id": "request/monorepo/main/1", "queue": "monorepo/main", "uri": "git://monorepo/main/HEAD", "build_strategy": "full"}
stovepipe-service-1  | 2026-07-13T15:41:15.784Z	DEBUG	consumer/consumer.go:479	message processed successfully	{"controller": "process", "topic_key": "process", "message_id": "request/monorepo/main/1", "partition_key": "monorepo/main", "attempt": 1, "elapsed_ms": 7}
stovepipe-service-1  | 2026-07-13T15:41:15.856Z	DEBUG	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:191	retrieved leased partitions	{"topic": "process", "count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.857Z	DEBUG	queue_mysql.subscriber_heartbeat_store	mysql/subscriber_heartbeat_store.go:95	found active subscribers	{"topic": "process", "count": 0, "subscribers": []}
stovepipe-service-1  | 2026-07-13T15:41:15.857Z	DEBUG	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:232	discovered partitions	{"topic": "process", "count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.858Z	DEBUG	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:83	acquired lease	{"topic": "process", "partition_key": "monorepo/main"}
stovepipe-service-1  | 2026-07-13T15:41:15.858Z	INFO	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:294	completed partition discovery and acquisition	{"topic": "process", "discovered_count": 1, "acquired_count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.858Z	DEBUG	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:191	retrieved leased partitions	{"topic": "process", "count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.864Z	DEBUG	queue_mysql.message_store	mysql/message_store.go:217	fetched messages	{"topic": "process", "partition_key": "monorepo/main", "count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.957Z	DEBUG	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:191	retrieved leased partitions	{"topic": "process", "count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.957Z	DEBUG	queue_mysql.subscriber_heartbeat_store	mysql/subscriber_heartbeat_store.go:95	found active subscribers	{"topic": "process", "count": 0, "subscribers": []}
stovepipe-service-1  | 2026-07-13T15:41:15.958Z	DEBUG	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:232	discovered partitions	{"topic": "process", "count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.959Z	DEBUG	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:83	acquired lease	{"topic": "process", "partition_key": "monorepo/main"}
stovepipe-service-1  | 2026-07-13T15:41:15.959Z	INFO	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:294	completed partition discovery and acquisition	{"topic": "process", "discovered_count": 1, "acquired_count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.959Z	DEBUG	queue_mysql.partition_lease_store	mysql/partition_lease_store.go:191	retrieved leased partitions	{"topic": "process", "count": 1}
stovepipe-service-1  | 2026-07-13T15:41:15.964Z	DEBUG	queue_mysql.message_store	mysql/message_store.go:217	fetched messages	{"topic": "process", "partition_key": "monorepo/main", "count": 0}

[behinddwalls]

The happy path is correct and the version-arithmetic convention (assign after CAS success) is followed throughout — and nice job picking up the #324 feedback (empty-pointer log message, the TODOs). But the failure paths of the admit workflow have one real defect (the slot leak, first inline comment) and two shape issues that I think should be addressed before this merges.

The three main findings share one fix shape: claim slot → re-check staleness against the reloaded pointer → markProcessing returns whether it actually transitioned → on a lost race or error, compensating-decrement the slot.

[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-admit
git rebase --onto origin/main 0c435d12ab8eeba953ea65e940c9deccd522d5cb mnoah1/stovepipe-process-admit
# resolve conflicts, then:
git push --force-with-lease

Then update this PR's base branch:

gh pr edit 335 --base main