[self-care:docs-build-time-investigator] Remove cross-workflow dashboard handoff from docs Pages builds

### Summary
The docs Pages workflow is already cache-hot for `node_modules` and uses cached dashboard snapshots, but it still spends about half of its end-to-end time waiting for a second workflow dispatch and handoff. Across 10 comparable successful scheduled runs on the same SHA, the median full `docs.yml` duration was 114s while the median `dashboard` job alone was 51s. Replacing the dispatched `dashboard-build.yml` call with an in-workflow reusable job invocation or folding the dashboard build into `docs.yml` would remove most of that orchestration overhead without changing freshness or deployment behavior.

### Timing evidence
Evidence window: 2026-09-09 08:02Z to 2026-09-09 11:23Z. Sample: 10 comparable successful scheduled `docs.yml` runs on commit `5875a57b8ab5fd5e918beafe85d1ff664235f997`, plus their paired `dashboard-build.yml` runs.

Median / p90 timings:
- Full `docs.yml`: 114s / 135s
- `docs.yml` `dashboard` job: 51s / 55s
- `docs.yml` `build` job: 36s / 41s
- `docs.yml` `deploy` job: 10s / 14s
- `dashboard-build.yml` full workflow: 42s / 45s
- `dashboard-build.yml` `activity` job: 7s / 7s
- `dashboard-build.yml` `build` job: 25s / 30s

Queue vs execution:
- `docs.yml` median queue before `dashboard` starts: 4s
- `docs.yml` median queue before `build` starts: 60s
- `docs.yml` median queue before `deploy` starts: 99s
- `dashboard-build.yml` median execution: 42s, which accounts for most of the 60s wait before the parent `build` job can start.

Repeated hot-path step medians from trusted Actions metadata:
- `docs.yml` `Set up Node.js`: 7s
- `docs.yml` `Restore node_modules`: 8s
- `docs.yml` `Build documentation`: 7s
- `dashboard-build.yml` `Restore collected activity data`: 6s
- `dashboard-build.yml` `Build Dashboard Language sources`: 3s
- `dashboard-build.yml` `Upload dashboard artifact`: 4s
- `docs.yml` `Upload Pages artifact`: 4s

Observed cache behavior from job metadata/log-connected step outcomes:
- `docs.yml` `Restore node_modules` ran in all 10 samples and `Install dependencies` was skipped in all 10, indicating cache hits for the lockfile key.
- `dashboard-build.yml` `Check for a cached activity snapshot` ran in all 10 paired runs and `Dispatch activity refresh` was skipped in all 10, indicating reuse of cached activity snapshots in `cache` mode.
- `docs.yml` always still executed `Mount dashboard at /cao`, so the handoff path still pays for either cache restore lookup or artifact download after waiting for the child workflow to finish.

Outliers disclosed:
- Recent failed `docs.yml` runs `34337999322`, `34336600742`, and `34331124406` were excluded from timing baselines.
- Successful run `34335678483` had a slower `deploy` job at 44s; this affected p90 but not the median bottleneck finding.

Confidence: medium-high. The compared runs share trigger (`schedule`) and source revision, and the dominant cost is stable across the sample.

### Bottleneck
The dominant repeated cost is not dependency installation, Astro generation, or Pages packaging. Those steps are already single-digit seconds with warm caches. The bottleneck is orchestration overhead from dispatching `dashboard-build.yml`, waiting for that separate workflow to complete, then restoring/downloading its output before the parent `build` job can proceed. The child workflow does only ~25s of actual dashboard build work in its `build` job, but the parent spends ~51s in the `dashboard` gate and ~60s before `build` can even start.

Relevant source locations:
- `.github/workflows/docs.yml`: `dashboard` job dispatch, `build` job `needs: dashboard`, and `Restore dashboard from cache` / `Mount dashboard at /cao`
- `.github/workflows/dashboard-build.yml`: cached activity lookup plus dashboard assembly and artifact/cache publication

### Recommended changes
Replace the workflow-dispatch handoff with a direct reusable execution path so `docs.yml` can consume dashboard outputs inside the same workflow run.

Concretely:
1. Convert `dashboard-build.yml` to support `workflow_call` in addition to `workflow_dispatch`, or move its current `build` logic into a reusable composite/reusable workflow job.
2. Invoke that reusable job directly from `docs.yml` instead of `node dashboard/dispatch-workflow.mjs`.
3. Pass the generated dashboard path as a normal job output or shared workspace/artifact within the same run, avoiding the extra cross-workflow cache keying (`cao-dashboard-${{ github.run_id }}-${{ github.run_attempt }}`) and post-dispatch fetch.
4. Keep the current `mode: cache` activity behavior so freshness and cache reuse stay unchanged.

This keeps correctness the same: same trusted source checkout, same cached activity policy, same Pages upload, but removes the extra workflow boundary.

### Expected effect and validation
Expected effect: save about 30–40 seconds per scheduled docs build, primarily by eliminating the separate workflow dispatch, child-run startup, and output handoff. That is roughly 26%–35% of the current 114s median full workflow time, exceeding the 15% threshold.

Validation after rollout:
1. Compare at least five post-change successful scheduled runs on a single SHA.
2. Recompute median / p90 for full `docs.yml` and the dashboard-producing path.
3. Acceptance check: median full workflow time drops by at least 30s, while dashboard content, Pages deployment success, and activity snapshot freshness remain unchanged.

### Caveats
- This recommendation is intentionally limited to orchestration overhead; current evidence does not justify changes to dependency caching or Astro build caching because those steps are already warm and small in the sampled runs.
- If the workflow split is required for isolation or reuse outside `docs.yml`, the reusable path should preserve that separation logically while avoiding a separate Actions run for the common docs path.
- The evidence window is short because recent scheduled runs were frequent and on the same SHA; broader historical validation is still recommended after implementation.

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

### References
- `docs.yml` runs: 34345182997, 34343367088, 34341957606, 34340838821, 34340006581, 34335678483, 34334693840, 34332404246, 34329463257, 34326951814
- `dashboard-build.yml` runs: 34345198898, 34343380008, 34341968526, 34340851288, 34340017328, 34335690665, 34334762402, 34332417805, 34329476654, 34326963085
- Example run links:
- https://github.com/githubnext/gh-aw-cao/actions/runs/34345182997
- https://github.com/githubnext/gh-aw-cao/actions/runs/34345198898
- https://github.com/githubnext/gh-aw-cao/actions/runs/34335678483

> Generated by [SelfCare / Docs Build Time](https://github.com/githubnext/gh-aw-cao/actions/runs/34345129894) · pi · gpt54 · 49.7 AIC · ⌖ 8.55 AIC · ⊞ 8.8K · [◷](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 23, 2026, 11:28 AM UTC

Start with .github/workflows/docs.yml, especially the dashboard dispatch, build job needs, and dashboard restore/mount steps, then compare the cached activity lookup and dashboard assembly in .github/workflows/dashboard-build.yml. Run the scheduled docs workflow or inspect the referenced successful runs. Done means the same dashboard and Pages deployment behavior remains, while at least five post-change runs show a median reduction of 30 seconds or more and unchanged activity freshness.

Written by the indexing model from the issue text.