docs: confirm review pipeline already routes through orchestrator/free, not NIM directly

CHANGELOG.md

@@ -68,6 +68,40 @@
 - Raised `hourly-review-repair.yml`'s discovery ceiling from 50 to 200 while rotating deterministic 50-PR deep-inspection windows by hourly run number. The scheduler hydrates only the selected window and stops immediately after its single dispatch, preserving access to newer PRs without quadrupling expensive review/check/comment work. See `docs/doctoring/hourly-review-repair-single-file-consolidation.md`'s 2026-09-03 follow-up.
 
 ## [Unreleased]
+- **Document (no code change yet, correction to an earlier same-day entry): Noema/OpenCode/Strix review's
+  model-selection layer routes through contextual-orchestrator's `orchestrator/free`, but the sidecar/egress
+  infrastructure layer four consumers actually run on does not yet.** This entry originally claimed the
+  routing was already fully implemented; @seonghobae disputed that framing on `.github#1884` and the dispute
+  held up under independent re-verification. `opencode.jsonc` (only `contextual-orchestrator` enabled, model
+  pinned to `orchestrator/free`) and `opencode-review-dispatch.yml`'s `OPENCODE_MODEL_CANDIDATES` are
+  correct as originally audited. But `scripts/ci/contextual_orchestrator_review_sidecar.sh` — the runtime
+  path `noema-review.yml`, `strix.yml`, `opencode-review-dispatch.yml`, and `pr-review-autofix.yml` all still
+  use — still injects all five raw provider secrets (including both NIM keys), clones and runs
+  `contextual-orchestrator` fresh on the calling runner per invocation, and performs multi-provider model
+  discovery in-process on that runner; `strix.yml`'s `harden-runner` step is still `egress-policy: audit`,
+  not `block`. None of the four consumers has migrated onto the newer `orchestrator-free-sidecar` composite
+  action (`.github#1736`) meant to centralize this. Tracked by `.github#1759` and
+  `contextual-orchestrator#1041` comment `5550412102`. Also fixed a stale gap-baseline note:
+  `tests/test_pr_review_autofix_nvidia_nim_contract.py`'s hourly-cron test, flagged not-yet-fixed on
+  2026-09-04, was fixed by `#1877` the same day. See `docs/product-technical-gap-baseline.md`'s 2026-09-05
+  entry (corrected 2026-09-05) for the full audit trail. 2026-09-06 follow-up in the same entry: records the
+  `orchestrator/free` retry-stacking root cause (`contextual-orchestrator#1081`), the sidecar pin advance that
+  delivered it (`#1951`), the rule for what counts as a post-advance run, and the first post-pin measurement
+  (`.github#1661` run `34008191123`: pin `414f2297…` live, preflight 0 of 12 routes ready, review request never
+  made), then the confirming measurements (`.github#1946` run `34008655765`: 180 s per gateway request against
+  540 s under the old pin; three post-advance Strix scans at `attempt=1/1` throughout) — status "fixed,
+  delivery confirmed, effect confirmed"; the residuals are capacity (`#1948`) and
+  `contextual-orchestrator#1082`. A further 2026-09-06 note locates the 90 s the residual entry attributes to
+  "the transport's recv default" at its source — `ModelClient.__init__(timeout: int = 90)`,
+  `contextual_orchestrator/orchestrator.py:1696` at `contextual-orchestrator@414f2297`, the pinned SHA — and
+  records `contextual-orchestrator#1053` as the upstream change that removes it (`timeout: float | None =
+  None`), so the inference-path half of that open question already has a claimed fix upstream and only the
+  preflight-probe deadline stays open here.
+  A 2026-09-06 15:37Z `noema-review` failure on this PR's own head, repeated on `#1187` 65 seconds later, first looked like a fourth residual shape and on reading the `noema-sidecar-evidence` artifacts turned out not to be one. Two claims are retracted in the entry rather than edited away: nothing was served (`served_model` names the last route *attempted*, and both runs end `provider_attempt_failed ... TimeoutError` -> `circuit_failure` -> `request_failed status=502`), and the 90 s `ModelClient` default is operative here (the gateway ran 24 internal attempts summing to ~11,500 s against a 1,424 s wall clock, about 8-9x concurrency, four of them at 89.5-92 s), so this is not evidence against `contextual-orchestrator#1053` and the `#1053` lane was told so directly. What survives is that the durations are bimodal: 11 of 24 attempts on `#1884` and 12 of 24 on `#1187` exceeded 600 s, to 1,333.7 s, with medians of 478.3 s and 631.3 s -- a population no 90 s bound explains. The consequence stated in the entry is that removing the implicit timeout should make these runs longer rather than shorter unless the long population is addressed too, offered as a two-sample prediction rather than a proven regression. Preflight read `ready_count 6` in both runs, so capacity is ruled out by artifact rather than inference, and `circuit_failure`/`circuit_opened` fire on this path, consistent with `#1082` scoping its defect to the passthrough walk.
+  A third run 25 minutes later (`#1967` `533b86b8`, run 34039136693, artifact 9992585682) is the capacity class rather than this one and is recorded so the two are not merged: it ends `429 rate_limit_exceeded` with preflight `ready_count 1`, 46 `HTTPError` against 5 `TimeoutError`, and 45 of 51 attempts under 10 s at a 0.1 s median. The bimodal finding stays a two-sample claim. That run is also the first observed boot where `#1949`'s postponement rule spent a second pass (`postponed_probed_count` 10) and readiness still finished at 1 of 24, with `escalations_used` 0.
+  A 2026-09-07 entry records that the whole central review pipeline was dark on an identity allowlist rather than on model capability, and that it has since been fixed. Required workflows run under `pull_request_target` with a read-only token, so they mint an OpenCode App token and send `repos/.../dispatches` as `opencode-agent[bot]`, while the receiving gate admitted only `github-actions[bot]` via `vars.OPENCODE_REPOSITORY_DISPATCH_ACTOR` -- every App-token dispatch was rejected at `validate-pr-metadata`/`validate-dispatch` with all review jobs `skipped`, so the required job's promise that "the dispatch workflow will rerun this failed job" could never be kept. The variable was identical in the one authorized run since 2026-08-31 (`33998627665`, actor `github-actions[bot]`, the merge-scheduler path) and in the rejected ones, so the defect was two senders against a one-entry allowlist, not a drifted value; `codeql-scan-dispatch.yml`, fed only by the App-token sender, had 0 successes across 2352 runs. Fixed by owner action between 00:07Z and 00:22:49Z on 2026-09-07 (that workflow now shows 5 successes, all `opencode-agent[bot]`). Tracked on `#1927`/`#1929`, with `#1925` a separate defect on the same workflow; no PR diff could carry the fix because an Actions variable is not repository content.
+  The same entry records the free pool resolving to a single provider family in three independent runs on 2026-09-06 (`ready_count` 6/5/6 of 24 against `target_ready` 8, every ready route `nvidia_nim` or `nvidia_nim_sub`, Bytez failing at discovery with `http_status_500` and both OpenRouter free routes deferred on 429), which makes the standing NIM-removal target cost-bearing today: removing direct NIM communication would leave the free pool empty. It also notes that `free_account_diversity` already exists in `contextual_orchestrator_review_launcher.py::_with_discovery_counts` but is catalog-scoped, absent from the uploaded `strix-plain-chat-preflight-v2` report, and account-axis (`provider_account` is the identity function, correctly so for rate-limit isolation) -- so it reads 2 where outage diversity is 1. Tracked on `#1915`.
+  Finally, the entry records three of this repository's own claims being retracted under independent count. `#2000` reported a 6 h 00 m 17 s Strix run ending `cancelled` with no verdict; a cross-family session matched the artifact's audit boundary exactly and showed the main route had 837 starts but 564 recorded failures, leaving 273 unclassifiable because the log emits no success-shaped event. "837 consecutive failures", "the caller re-selecting a dead route", and "killed by the 6-hour ceiling" were all withdrawn; with zero `request_id` fields in the evidence, caller retry and independent concurrent requests are indistinguishable, and `provider_exhausted: 0` is an absence rather than a demonstration. What survives is the start distribution (92% on one route), the aggregate counts, and a required check that ended with no verdict -- the state `#1756` sweeps. Emitting a per-request correlation id is named as the prerequisite for any further diagnosis. Refs #1915, #1927, #1929, #2000, #1756.
 - Include merge-scheduler entrypoint, core, and regression-test changes in
   the existing runtime-quality workflow's trigger and suite selector. Scheduler
   workflow edits retain queue checks and also select the full review-repair