ci: publish to Pages from dashboard_refresh's already-fresh path too

[Jammy2211]

Summary

dashboard_refresh.yml dispatched the Pages publisher only from inside its
self-heal branch. The job's first act is if check; then exit 0; fi, so when the
committed render was already fresh it returned before reaching the dispatch — and the
commit that made it fresh was pushed by mind_ledger_merge.yml with GITHUB_TOKEN,
which fires no push event, so pages_dashboard.yml's own
push: main, paths: [dashboard.html] trigger never saw it either.

The published board could therefore strand indefinitely while dashboard.html on main
was correct. Two properties made it worse than a lag:

• Not self-healing. The nightly cron: "20 3 * * *" takes the same early-return
  path, so nothing recovered it. It stayed stale until some push to main touching
  dashboard.html happened to be made with a non-GITHUB_TOKEN credential.
• Inverted failure. The page goes stale because the session did its job properly.
  Had the render been left stale, the self-heal would have fired and published. So every
  workflow run is green and the repo copy is perfect while the published surface is wrong.

Observed 2026-08-27: a retired prompt kept rendering as a pickable chip ~1.5h after its
retirement landed on main, and was re-picked as already-shipped work. Pages Dashboard
last ran 19:15:13Z; the ledger merges at 19:29, 19:30 and 20:09 produced Mind Ledger Merge / Dashboard Refresh / Lifecycle Drift runs and no Pages Dashboard run.

This is the third bite of the same GITHUB_TOKEN trap. The fix for bite two
(a305a293) added the right dispatch on the wrong branch of the flow.

Fixes #361.

API Changes

None. CI workflow only — no library source, no public symbols, no dependency changes.

Test Plan

• pytest tests/ in PyAutoMind — 267 passed

• YAML parses; permissions: actions: write already declared (no permission change)

• bash -n on the extracted step body (GitHub runs run: as bash -e)

• Behavioural control test with gh and the renderer stubbed, run under bash -e:

  render	event	pre-fix	post-fix
  fresh	push	0 dispatches	1
  fresh	schedule	0 dispatches	1
  fresh	workflow_dispatch	0	1
  fresh	pull_request	0	0
  stale	pull_request	exit 1	exit 1

  The pre-fix column is the control: it confirms the test actually detects the bug rather
  than passing vacuously. The schedule row is the one that makes the nightly cron a real
  backstop for the first time.

• Post-merge replay: land a ledger-only change through mind_ledger_merge.yml and
  confirm a Pages Dashboard run appears for it — the real chain, not an inference
  from a green Dashboard Refresh.

Deliberately out of scope

• mind_ledger_merge.yml's heal loop. Adding pages_dashboard.yml there was
  considered and declined: it already dispatches dashboard_refresh.yml on every merge,
  so with this change the publish is guaranteed through that path, and a second dispatch
  would fire a duplicate deploy on every ledger merge.
• The sibling boards. PyAutoHands/release_board.yml,
  PyAutoMemory/knowledge_board.yml and PyAutoScientist/organism_board.yml each render
  and actions/deploy-pages@v4 in a single run, so they cannot desync. PyAutoHeart has
  no board workflow. Checked 2026-08-27; no change needed in any of them.

Ship gate — Heart override

Heart was RED at ship time and the human authorized shipping anyway, explicitly. The
RED reason, verbatim:

release validation FAILED (stage integrate)

Yellows: workspace validation timeout (autolens_test scripts/multi_dataset/shared_preloads.py,
cloud#32902243623) · manifest drift: session-start hooks (generated) — 34 mismatch(es) ·
PyAutoFit: open PR 8d old.

This is not the AUTONOMY.md corrective-PR exception — that permits only a fix scoped
to the RED reason itself, and this change is unrelated to release validation. It is a
deliberate human override, recorded here so the merge decision is auditable.

Generated by the PyAutoLabs agent workflow.