docs(stovepipe): simplify validation state contract

Author: mnoah1

doc/rfc/stovepipe/get-validation-api.md

@@ -21,21 +21,6 @@ message GetValidationRequest {
     string page_token = 5;
 }
 
-enum ValidationLifecycleState {
-    VALIDATION_LIFECYCLE_STATE_UNSPECIFIED = 0;
-    VALIDATION_LIFECYCLE_STATE_ACCEPTED = 1;
-    VALIDATION_LIFECYCLE_STATE_RUNNING = 2;
-    VALIDATION_LIFECYCLE_STATE_TERMINAL = 3;
-}
-
-enum ValidationTerminalOutcome {
-    VALIDATION_TERMINAL_OUTCOME_UNSPECIFIED = 0;
-    VALIDATION_TERMINAL_OUTCOME_SUCCEEDED = 1;
-    VALIDATION_TERMINAL_OUTCOME_FAILED = 2;
-    VALIDATION_TERMINAL_OUTCOME_CANCELLED = 3;
-    VALIDATION_TERMINAL_OUTCOME_SUPERSEDED = 4;
-}
-
 message ValidationResult {
     double degree = 1;
 }
@@ -50,20 +35,19 @@ message GetValidationResponse {
     string queue = 2;
     string change_uri = 3;
     string base_uri = 4;
-    ValidationLifecycleState lifecycle_state = 5;
-    ValidationTerminalOutcome terminal_outcome = 6;
-    ValidationResult repository_result = 7;
-    bool project_results_complete = 8;
-    repeated ProjectValidation projects = 9;
-    string next_page_token = 10;
+    string request_state = 5;
+    ValidationResult repository_result = 6;
+    bool project_results_complete = 7;
+    repeated ProjectValidation projects = 8;
+    string next_page_token = 9;
 }
 
 service Stovepipe {
     rpc GetValidation(GetValidationRequest) returns (GetValidationResponse) {}
 }
 ```
 
-Message fields preserve presence. An absent `repository_result` or `ProjectValidation.result` means no fact has been recorded; it never means green. `terminal_outcome` is set only when `lifecycle_state` is terminal. `project_results_complete` is true only after every project in the persisted manifest has exactly one durable result and the request's completion marker has been written.
+Message fields preserve presence. An absent `repository_result` or `ProjectValidation.result` means no fact has been recorded; it never means green. `project_results_complete` is true only after every project in the persisted manifest has exactly one durable result and the request's completion marker has been written.
 
 The existing degree scale answers “how broken is this scope”: `0.0` is fully green, `1.0` is fully broken, and project analysis may assign intermediate values. The API preserves those Stovepipe semantics rather than inverting the scale at the wire boundary.
 
@@ -75,18 +59,9 @@ The controller verifies that the loaded Request has the requested queue and URI
 
 Ingest claims `request_uri` before creating the Request so concurrent ingests converge without a cross-record transaction. A lookup racing that sequence can therefore observe a mapping whose Request is not present yet. `GetValidation` treats that condition as unavailable and retryable rather than not found or immediate corruption. Repeated occurrences are surfaced through consistency metrics and require repair; a mapping to a Request with a different queue or URI is an internal consistency error.
 
-Lifecycle is a coarse, stable API projection rather than a duplicate of every internal request state:
-
-| Request state | Lifecycle state | Terminal outcome |
-|---|---|---|
-| `accepted` | `ACCEPTED` | unset |
-| `processing` | `RUNNING` | unset |
-| `succeeded` | `TERMINAL` | `SUCCEEDED` |
-| `failed` | `TERMINAL` | `FAILED` |
-| `cancelled` | `TERMINAL` | `CANCELLED` |
-| `superseded` | `TERMINAL` | `SUPERSEDED` |
+`request_state` uses the same stable public vocabulary as [Stovepipe Request History](request-history-api.md): `accepted`, `processing`, `succeeded`, `failed`, `cancelled`, and `superseded`. One value identifies both lifecycle position and terminal outcome without permitting contradictory field combinations. The wire field is a string, following SubmitQueue's current-status and history APIs, so clients can tolerate additive vocabulary changes. It is projected explicitly from Stovepipe's internal `RequestState`; no SubmitQueue domain enum is shared across the boundary.
 
-This vocabulary is local to `GetValidation`; it does not depend on a future status-list API. New internal states map into one of these lifecycle phases without adding a wire value unless clients need to distinguish them.
+`failed` retains the current conservative meaning: either validation failed or the request could not continue. The API does not synthesize a `COMPLETED` versus `ERROR` distinction that the Request does not persist. Adding that distinction later requires a durable outcome classification first, followed by an additive response field.
 
 When `project` is omitted, the response contains one bounded page of the manifest, including planned projects whose result is not yet present. When `project` is present, it must be a non-empty project in the manifest; the response contains only that project and no continuation token. A nonzero page size or nonempty page token with an exact project selector is invalid.
 
@@ -134,4 +109,4 @@ Authorization follows the queue policy used by other Stovepipe reads. Both the r
 
 The endpoint is enabled only after project-manifest persistence, project-fact recording, the completion marker, and `end_validation` publish ordering are deployed. This avoids exposing a nominal all-project response that silently omits the service list.
 
-Contract and controller tests cover lifecycle projection, result presence at degree zero, whole-repository and project independence, exact project selection, incomplete and complete manifests, empty and chunked manifests, first/middle/final pages, token query binding, stable ordering, cross-queue isolation, mapping-before-Request retries, mismatched identities, byte-distinct keys, storage limits, and publish-after-completion ordering.
+Contract and controller tests cover request-state projection, result presence at degree zero, whole-repository and project independence, exact project selection, incomplete and complete manifests, empty and chunked manifests, first/middle/final pages, token query binding, stable ordering, cross-queue isolation, mapping-before-Request retries, mismatched identities, byte-distinct keys, storage limits, and publish-after-completion ordering.