Track per-workflow Actions status and link failed checks to workflow overview

[lubianat]

I did not add it in the context of #14, as I needed more time to think about ux.

The dashboard currently stores and displays only an aggregate workflow_run_status per repo (SUCCESS/FAILURE/PENDING/NO_WORKFLOWS), which makes it hard to see which workflow is
failing.

When a repo shows a failed checks icon, we don’t expose the failing workflow directly.
Example target URL shape we want to support:
https://github.com/ome/ngff/actions/workflows/pages/pages-build-deployment

Add per-workflow status data and use it in the UI:

1. In status generation, keep existing workflow_run_status (for compatibility), and add:
   • workflow_run_statuses keyed by workflow ID.
2. Store, per workflow ID:
   • name
   • status (SUCCESS / FAILURE / PENDING)
   • workflow_url (workflow overview URL)
3. In the dashboard UI:
   • display it (still not sure on what is best!)

I would not store run-specific URLs/IDs (e.g. run_url) to avoid config churn:

• New runs with unchanged per-workflow status should not create unnecessary diffs in generated.yml.

[pwalczysko]

In the dashboard UI:

* display it (still not sure on what is best!)

I would be cautious of cluttering the UI with new lines. If the repo "is red", then an average user would immediately go into the repo and look for the cause of the redness until found imho.
Thus, there "might be" no need for specifical show of all the workflow statuses in the UI. As for collecting of the data, yes, imho it is good to have the info collected.

This ^^^ boils down for me to a suggestion: "Can we be precise only in the moment when the workflow fails and show the failing workflow?"

But not sure if my suggestion is not redundant (because it is included in your plan) or even if it is very good (because making this dashboard bigger/longer/more complex for the UI-bound user is very much not a great idea imho.