ci(vv): aggregate Pages publish into one workflow to avoid concurrency cancellations

[renatosfagundes]

Summary

• Promotes the V&V Pages-publish CI hotfix from development to main, fixing the publish-race that left 2-3 of the five module HTML reports stale on every push to a trunk branch since the v2.0.0 release.
• Replaces the per-workflow publish-pages jobs with a single aggregator workflow (.github/workflows/publish-vv-reports.yml) triggered by workflow_run on completion of any of the five module V&V workflows.
• Aggregator gates on gh run list for every workflow that ran on the SHA; treats "no run for this SHA" as not-applicable (single-module pushes deploy what ran), and deploys once every triggered workflow completes successfully.
• Restores branch-namespaced report URLs (vv_<module>/<branch>/), preserving dev/main isolation that the previous per-module destination_dir provided and that every V&V step-summary browse-link still expects.
• Refreshes the "Reports are published" comment blocks in all five vv-*.yml files and the matching paragraph in publish-index.yml to point readers at publish-vv-reports.yml.
• No source-code, requirements, or model changes — CI infrastructure only.

Related Issue

Closes #127

Change Type

• feat
• fix
• docs
• test
• ci
• refactor/chore

AEB Areas Affected

• Perception
• Decision Logic
• Driver Alerts
• Braking Control
• State Machine
• CAN Interface
• UDS Diagnostics
• Integration
• Documentation only

Requirements Impacted

Functional Requirements

• N/A — no module behaviour changes; CI publication path only.

Non-Functional Requirements

• NFR-VV-CI: every push to development/main whose V&V gates pass must publish the corresponding module reports to GitHub Pages.

Artifacts Updated

• Requirements document
• Modeling document
• Simulink / Stateflow model
• C source code
• Tests
• CI workflow
• README / SCM documentation
• CHANGELOG

Validation Evidence

• Local build passes
• Automated tests pass
• CI passes
• Traceability updated
• Safety-relevant impact assessed
• Documentation updated

Evidence

Failure observed on main HEAD (5cf8eba) — the v2.0.0 release:

Workflow	Stack job	publish-pages
Perception V&V	success	deployed
PID + Alert V&V	success	deployed
Publish V&V index	—	deployed
CAN V&V	success	cancelled
Decision V&V	success	cancelled
UDS V&V	success	cancelled

Cancelled jobs entered completed/cancelled ~3 s after start with steps: [] — classic "third arrival to a cancel-in-progress: false group cancels the previously pending job" pattern.

Dry-run of the fixed aggregator against the same SHA (no deploy side effects, gh run list + gh run view):

SHA: 5cf8eba6f472513b27b212be3207230a8f40838a   (main, the broken release)

  Workflow            run id        wf concl    stack concl
  CAN V&V             25447897623   cancelled   success
  Decision V&V        25447896084   cancelled   success
  Perception V&V      25447892593   success     success
  PID + Alert V&V     25447891296   success     success
  UDS V&V             25447894289   cancelled   success

  FIXED gate -> DEPLOY (5 module reports published)

Same dry-run on a real partial-trigger push (b89ba86d02 on development, where only 4 of 5 V&V workflows fired because path filters didn't match Perception):

SHA: b89ba86d02b5f3779f4d504837bcfd9097560022

  Workflow            run id        stack concl
  CAN V&V             25413361683   success
  Decision V&V        25413361675   success
  Perception V&V      —             (no run for this SHA — skipped)
  PID + Alert V&V     25413361680   success
  UDS V&V             25413361684   success

  FIXED gate -> DEPLOY (4 module reports published, Perception keeps prior gh-pages content)

Local validation: yaml.safe_load passes on all 7 touched workflow files.

Reviewer Notes

• This PR is the dev → main promotion of the bundle already approved on PR #126 (Rian's review + follow-up fixes). The diff into main is exactly that bundle, since the dev and main trees were identical at the v2.0.0 release point.
• Focus on the Gate step in publish-vv-reports.yml: it's the only piece preventing duplicate or empty deploys. The three "exit silently" branches must not error or they cancel their own concurrency slot.
• The aggregator hardcodes the five workflow name: strings in three places (workflow_run trigger list, gate's bash array, art_prefix table). Inline # NOTE: comments flag this for future maintainers; there's no CI check enforcing the sync.
• The aggregator still uses concurrency: gh-pages-deploy so it serialises with publish-index.yml. With per-module publish jobs gone, max in-flight on the group is 2 (this one + index) — well below the 1+1 cancel threshold.

Risks / Open Points

• First CI proof comes after merge, not before. The diff doesn't match any vv-*.yml paths: filter, so merging this PR won't itself trigger any V&V workflow — true end-to-end validation lands with the next source-code commit on main.
• Workflow-name fragility: any future rename of a workflow's name: field silently drops that module unless all three lists in publish-vv-reports.yml are updated. Adding a CI check that diffs the lists is a sensible follow-up.
• Artefact retention: gh run download reads from per-run artefacts (90-day default). A re-run of the aggregator alone on an old SHA whose artefacts have expired would fail to fetch; acceptable because Pages publication is forward-only.
• Manual recovery on partial failures: if 4 of 5 modules pass and 1 fails on a push, the aggregator skips deploy. After the failing module is re-run successfully, the aggregator fires from that re-run event and deploys. Worth a README note once this has been observed in practice.