docs(demo): correct the sample trail to states the pipeline emits

## Summary

### Why?

The sample table showed `accepted → started → batched → speculating → landed`, which cannot happen. `RequestStatusSpeculating` is defined in the entity package and never published by any non-test code — along with `validating`, `batching`, `speculated`, `building`, `built`, `waitingpath`, `landing` and `processing`. Nine of the eighteen statuses are dead vocabulary today.

Getting this wrong in the one place that shows what the tool looks like is worse than saying nothing, because it invites exactly the wrong conclusion: a request sitting on `batched` for minutes looks stuck, when its batch is in fact speculating and building normally with nothing to report it.

### What?

The sample is the real thing the renderer produces for a trail the pipeline can actually emit, and the text says plainly what the vocabulary is limited to and how to read a request that rests on `batched`.

The gap itself is CODEM-426.

## Test Plan

✅ Sample generated from the renderer rather than written by hand, so the column widths and rule lengths are the ones the tool produces.

Author: behinddwalls

doc/howto/PROVIDER-E2E.md

@@ -106,15 +106,17 @@ The table is there from the start — one row per land request, drawn before the
 
 ```
   REQUEST        CHANGES  ELAPSED  STAGE
-  ─────────────  ───────  ───────  ───────────────────────────────────────────────────
-  demo-queue/12  #31          34s  accepted → started → batched → speculating → landed
-  demo-queue/13  #32          31s  accepted → started → batched → speculating
+  ─────────────  ───────  ───────  ─────────────────────────────────────────────────
+  demo-queue/12  #31          34s  accepted → started → validated → batched → landed
+  demo-queue/13  #32          31s  accepted → started → validated → batched
   demo-queue/14  #33          28s  accepted → started
 
   ▸ 1 of 3 settled
 ```
 
-Each row shows the states its request passed through, not just the one it is in. That comes from the gateway's history API rather than from sampling the current status, so a request that batches and speculates between two ticks still shows both. `CHANGES` links to the pull request: on a terminal `#31` is clickable, and in a redirected run it is written out as a full URL instead. `ELAPSED` runs from the moment the gateway accepted the request and stops when it settles, so a finished row keeps the time it took rather than counting on.
+Each row shows the states its request passed through, not just the one it is in. That comes from the gateway's history API rather than from sampling the current status, so a transition between two polls is not missed. `CHANGES` links to the pull request: on a terminal `#31` is clickable, and in a redirected run it is written out as a full URL instead. `ELAPSED` runs from the moment the gateway accepted the request and stops when it settles, so a finished row keeps the time it took rather than counting on.
+
+The trail is only as detailed as what the pipeline reports, which today is `accepted`, `started`, `validated`, `batched` and then a terminal `landed`, `error` or `cancelled`. The finer-grained statuses the API defines — `speculating`, `building`, `landing` and the rest — are never published, so a request sits on `batched` for the whole of its active life even while its batch is speculating and building. Do not read that as the request being stuck.
 
 `STACKED=true` is the exception to the overlap: one request carries the whole chain, so it can only go in once every pull request in it exists. That is the atomic-stack path — the whole set reaches `main` in a single push, and the table shows it as the single row it is.