docs(stovepipe): rewrite workflow RFC around poll/ingest/greenness design (#275)

## Summary
### Why?

The previous workflow RFC described a webhook+poller, SHA-keyed,
batch/bisection-heavy pipeline. The design has since moved to a
poller-driven, VCS-agnostic model that records a greenness *degree* per
commit and refines it to per-project granularity for deployment gating.
The doc needed a full rewrite to reflect the design as it now stands
rather than a delta.

### What?

Rewrites `doc/rfc/stovepipe/workflow.md` as a self-contained design:

- VCS-agnostic identity: every commit/ref/head is an opaque URI owned by
a `SourceControl` extension (`git://remote/repo/ref/…/<sha>`); the build
system sits behind the build-runner extension and yields a target graph.
- `Queue` is the validation namespace (a named repo+ref) that namespaces
Request IDs, is the ingest handle, and owns the last-green URI +
greenness history — distinct from the messaging queue.
- Greenness is a degree (`0` green … `1` fully broken) with room for
partial breakage once projects exist; "not recorded" is not-green for
gating.
- Two-phase pipeline: ingest → process → build → buildsignal → record
(whole-repo greenness), then analyze → build → buildsignal → record
(per-project greenness). `record` is re-entrant and non-terminal;
`process` decides incremental-since-green vs full-monorepo via
SourceControl ancestry (history-rewrite fallback).
- `Hooks` extension is the downstream notification boundary for
green/not-green events.
- Carries over the fail-closed-to-not-green posture (DLQ reconciliation)
and dedup on `(Queue, head URI)`.
- Ends with Open Questions: greenness degree semantics, webhook
ingestion, project-mapping contract.

## Test Plan


## Issues


## Stack
1. @ #275
1. #276
1. #277

Author: behinddwalls