[self-care:docs-build-time-investigator] Inline dashboard generation into Documentation Pages to remove cross-workflow handoff

The Documentation Pages workflow is consistently spending about half of its end-to-end runtime waiting on a separately dispatched dashboard build even though the main docs job already restores dependencies quickly and the Astro docs build itself is only a few seconds. Across 12 recent successful runs, median workflow time was 93.5s (p90 124s), with the `dashboard` job alone at 41s median (p90 44s) versus `build` at 26s median and `deploy` at 9s median. The clearest improvement is to build the dashboard directly inside `.github/workflows/docs.yml` instead of dispatching `.github/workflows/dashboard-build.yml` and round-tripping the result through Actions cache plus artifact upload/download.

**Action:** Docs workflow owners should collapse the dispatched dashboard build into the Documentation Pages workflow and accept the change when at least five comparable runs show end-to-end median time reduced by >=60s or >=15% without missing dashboard content or Pages deploy regressions.

### Summary
The current dependency cache is working: every sampled successful `build` job restored `node_modules`, skipped `npm ci`, and spent only 3-8s in dependency restore. The dominant repeated cost is the extra workflow hop for dashboard generation, not package installation. A single-workflow build should remove one workflow dispatch, one downstream workflow queue, one dashboard artifact cache save/restore pair, and the fallback artifact transfer path.

### Timing evidence
- Evidence window: latest 12 successful `docs.yml` runs from 2026-09-05 21:30 UTC to 2026-09-05 23:47 UTC; excluded 5 failed completed runs in the same 20-run window.
- Comparable sample: 10 scheduled runs on the same source revision `317a3ba5868a28e49d97b675e51f8a1bdac5caf0` plus 2 later successful runs on `d59fa8d913535c984c8b1faa2e833be1c4225b82`; 2 push-triggered successes are disclosed but were not the main basis for the recommendation because one had a 76s queue outlier before `dashboard` started.
- Full workflow duration: median 93.5s, p90 124s.
- Queue before `dashboard`: median 4s, p90 4s. One push outlier waited 76s before the first job started.
- `dashboard` job duration: median 41s, p90 44s.
- Queue between `dashboard` and `build`: median 3s, p90 5s.
- `build` job duration: median 26s, p90 33s.
- `deploy` job duration: median 9s, p90 11s.
- Inside `build`: `Restore node_modules` median 5s (p90 8s); `Build documentation` median 5s (p90 6s); `Restore dashboard from cache` median 0s (p90 1s); `Mount dashboard at /cao` median 1s (p90 2s); `Upload Pages artifact` median 2s (p90 3s).
- Logs from sampled successful runs show a cache hit for the Node dependency cache in post-job cleanup (`Cache hit occurred on the primary key ... not saving cache.`), confirming dependency caching is effective.
- Representative runs: 33999525076, 33998875195, 33998317645, 33997523195, 33996833026, 33996124117, 33995568715, 33994708936, 33993979486, 33993270151.

### Bottleneck
`.github/workflows/docs.yml` uses a dedicated `dashboard` job only to dispatch `.github/workflows/dashboard-build.yml`, wait for that workflow to complete, then recover its output via `actions/cache/restore` keyed by downstream run ID and optionally `actions/download-artifact`. That extra workflow contributes ~41s median by itself, while the remaining docs build work in the top-level workflow is ~35s including queue and deploy. Because the downstream dashboard build already performs its own activity recovery and uploads artifacts, the parent workflow pays orchestration overhead that does not improve dependency reuse inside `docs.yml`.

### Recommended changes
1. Replace the dispatch-based `dashboard` job in `.github/workflows/docs.yml` with an in-process dashboard build path that runs the same trusted source revision and reuses the existing build logic from `.github/workflows/dashboard-build.yml`.
2. Move the dashboard generation steps needed for Documentation Pages into a composite action or shared script invoked directly by `docs.yml` so the workflow no longer waits for a separate Actions run or exchanges the dashboard via cache/artifacts.
3. Keep the standalone `dashboard-build.yml` only for callers that truly need a reusable workflow boundary; for Documentation Pages, call the shared build implementation directly and place the generated dashboard under `dist/cao` before `upload-pages-artifact`.
4. After the change, remove the `actions/cache/save` / `actions/cache/restore` key path `cao-dashboard-${{ ... }}` and the fallback `actions/download-artifact` step from `docs.yml`, since they exist only to bridge the cross-workflow handoff.

### Expected effect and validation
- Expected effect: removing the downstream workflow dispatch and handoff should reclaim most of the `dashboard` job's 41s median duration plus several seconds of inter-job queueing. Even if direct in-workflow dashboard generation takes roughly the same compute time as the downstream build, avoiding separate workflow scheduling and output shuttling should comfortably exceed the 15% threshold and is likely to save around 35-45s end-to-end.
- Validation:
- Compare at least five scheduled runs on unchanged content before and after the change.
- Confirm median full workflow time drops from 93.5s by at least 15% or 60s, whichever is applicable.
- Confirm generated Pages output still includes the docs site and `/cao` dashboard content.
- Confirm no reduction in freshness, correctness, or deployment safety relative to the current trusted-source flow.

### Caveats
- This recommendation is for the Documentation Pages path only; preserve any security properties currently provided by checking out `github.workflow_sha` and using trusted local sources.
- The sample window is strong for schedule-triggered runs but narrow in calendar span because `docs.yml` runs frequently. One push-triggered success had a 76s queue outlier before any job started; that outlier was disclosed and not treated as a normal execution cost.
- I could not verify open issue duplication because `gh issue list` returned HTTP 502 from the sandbox proxy during this run, so maintainers should merge or close this if an equivalent open issue already exists.

### Control Plane
- Correlation ID: `33999482973-254`
- Central repository: `githubnext/gh-aw-cao`
- Control plane run: https://github.com/githubnext/gh-aw-cao/actions/runs/33999482973

### References
- Workflow source: `.github/workflows/docs.yml`
- Workflow source: `.github/workflows/dashboard-build.yml`
- Example docs runs: https://github.com/githubnext/gh-aw-cao/actions/runs/33999525076, https://github.com/githubnext/gh-aw-cao/actions/runs/33998875195, https://github.com/githubnext/gh-aw-cao/actions/runs/33998317645, https://github.com/githubnext/gh-aw-cao/actions/runs/33997523195, https://github.com/githubnext/gh-aw-cao/actions/runs/33996833026

> Generated by [SelfCare / Docs Build Time](https://github.com/githubnext/gh-aw-cao/actions/runs/33999637948) · pi · gpt54 · 38.5 AIC · ⌖ 8.55 AIC · ⊞ 8.7K · [◷](https://github.com/search?q=repo%3Agithubnext%2Fgh-aw-cao+is%3Aissue+%22gh-aw-workflow-call-id%3A+githubnext%2Fgh-aw-cao%2Fself-care-docs-build-time-investigator%22&type=issues)
> - [x] expires on Sep 19, 2026, 11:54 PM UTC

Start by reading .github/workflows/docs.yml and .github/workflows/dashboard-build.yml, tracing the dashboard dispatch, cache, artifact, and trusted-source handling. Identify the shared dashboard build logic and the path that places output under dist/cao. Done means the Pages workflow no longer uses the cross-workflow handoff, preserves docs and dashboard content, and meets the stated timing validation across at least five runs.

Written by the indexing model from the issue text.