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]

All committers have signed the CLA.