doc(stovepipe): build and buildsignal pipeline steps

[roychying]

Why?

Stovepipe's pipeline had design docs for process but nothing for the two stages downstream of it - build (triggers the build-runner) and buildsignal (polls it to completion). Both stages needed a documented contract before implementation could start, in particular because stovepipe can't reuse SubmitQueue's BuildRunner interface as-is: SubmitQueue validates stacks of batches, stovepipe validates a single URI against a baseline, and that mismatch has to be resolved deliberately rather than discovered mid-implementation.

What?

• doc/rfc/stovepipe/steps/build.md (new): documents the build stage end to end - the trigger-only algorithm, idempotency posture under at-least-once redelivery, error classification, edge cases (head == last-green, Phase 2 re-triggers), and the new Build entity/BuildStore/queue contract it needs. Defines the stovepipe BuildRunner contract (design sketch) with URI-based Trigger(headURI, baseURI, metadata) instead of SubmitQueue's batch-based trigger, explains why the contracts are kept separate (materialize-vs-checkout mismatch, baseline semantics batches can't express, URI ownership), and lays out - as open discussion, not settled decisions - alternative shapes for sharing the contract (single platform-level interface, metadata-smuggled scope, shared-backend-thin-contracts) and alternatives for how the build id could be keyed/deduped.
• doc/rfc/stovepipe/steps/buildsignal.md (new): documents the buildsignal poll loop - reusing SubmitQueue's buildsignal shape (poll cadence, PublishAfter-not-Nack primitive, error classification) pipe diverges: it only forwards to record once terminal

Test Plan

N/A

Issue

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

chenghan.ying seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[behinddwalls]

can we use relative to root paths than relative to current

[behinddwalls]

do we need to have it as buildrunner extension at the platform vs per technologu say buildkite, i don't think the idea of breaking the contract in places so defining somewhat similar thing in 2 places for status and cancel is fine..and we abstract away by the underlying impl like buildkite to so ? thoughts

[roychying]

1. paths fixed.
2. yes and this is one of the alternatives I'd already recorded. The shared-interface route does give a compile-time guarantee that both domains' Status/Cancel stay identical (I believe they should be?), but it costs fragmenting one conceptual contract across two packages, plus migrating SubmitQueue's already-shipped code onto promoted platform/base types for a half only SubmitQueue uses today. Your approach is what the doc now adopts.

[behinddwalls]

should be added anyway in both SQ and Stovepipe... currently there no metadata as such from SQ to be passed but i can think of things which might be valuable to pass like conflict graph info or any other decisions which maybe relevant to build.

cc: @JamyDev

[roychying]

Shall we decided the concrete shape here? my preference is leaving it deferred until there's a real consumer in either domain..