fix: platform status stays in_progress

[cgoea]

Motivation

Fixes ROCm/Quartz#66: a platform's summary.<platform>.status could already read failure while other pipelines on that same platform (e.g. jax, native_packages) had not reported anything yet. The rollup precedence (failure > in_progress > cancelled > success > skipped) let one pipeline's terminal failure shortcut past sibling pipelines that were still genuinely in flight and could still pass or fail on their own, so the platform's reported verdict was premature.

Technical Details

• Added rollup_sibling_statuses() in therock_status_document.py
• _build_platform_summary() in therock_summary.py now rolls each pipeline up to its own single status first
• Net effect: a platform only crystallizes to failure/cancelled once every expected sibling pipeline has reported a terminal status; until then it correctly stays in_progress.

Test Plan

• Updated therock_summary_test.py cases that previously asserted the premature-failure behavior
• Added companion tests (*_wins_once_every_sibling_is_terminal / *_drags_platform_once_siblings_are_terminal) verifying failure still correctly wins once every sibling pipeline has reported terminally, so no coverage was lost.

Test Result

• pytest scripts/: 475 passed

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

[HereThereBeDragons]

from afar i thought it makes sense to combine this with #57. what do you think?

my idea would be to extract from https://github.com/ROCm/therock/blob/main/.github/workflows/multi_arch_release.yml from the inputs the following:

    build_python_packages: true
    build_pytorch: true
    build_jax: true

and based on this and which archs are set

    linux_amdgpu_families: all
    windows_amdgpu_families: all

we can then scope the expected pipelines "live". (expected is always all pipelines and all archs. its more used to disable the expectation)

[cgoea]

from afar i thought it makes sense to combine this with #57. what do you think?

my idea would be to extract from https://github.com/ROCm/therock/blob/main/.github/workflows/multi_arch_release.yml from the inputs the following:

    build_python_packages: true
    build_pytorch: true
    build_jax: true

and based on this and which archs are set

    linux_amdgpu_families: all
    windows_amdgpu_families: all

we can then scope the expected pipelines "live". (expected is always all pipelines and all archs. its more used to disable the expectation)

I would keep it separate, and make a follow up PR against #57. #88 stacked on top of this one