Preserve truthful rail state while full details are loading

[jskoiz]

Verified against main at 715c52e.

Impact

The progressive loader can render either a stale full browser cache or a new quick payload while the full request runs. When stale full data already contains known workflow failures, isUpdating replaces those rows with a generic background-loading panel. When there is no cache, the quick payload intentionally marks billing unavailable with “Billing loads with full dashboard details,” but the billing card labels that transient state “billing blocked.”

Both presentations misstate known state during the same progressive-loading phase: confirmed cached failures disappear, and expected loading is shown as a permissions/error condition.

Concrete code references

• A stale full cache is rendered while updatingDetails is set.
• The quick payload uses an unavailable billing shape specifically to represent loading.
• The workflow card replaces all known rows whenever isUpdating is true.
• Every unavailable billing shape receives the same “billing blocked” badge.

Acceptance criteria

• Known cached workflow failures remain visible while a full refresh is in progress, with a clear updating/stale indication rather than being replaced by a generic panel.
• A quick payload's deferred billing state is presented as loading, not blocked or denied.
• A completed full payload with genuinely unavailable billing still presents the returned reason/fix as unavailable or blocked.
• When the full response succeeds, rail content switches to the new data without duplicating cached rows; when it fails, retained data is explicitly identified as cached/stale.
• Auth or dashboard-source changes must not preserve another source's rail data.

Test expectations

• Extend OperationalRail.test.tsx with isUpdating=true plus known failing runs and assert those rows remain visible.
• Add billing tests for quick/loading versus full/unavailable versus full/available states.
• Add an App-level progressive sequence test covering stale cache, pending full response, success, and failure.
• Run npm run test -- --project web and npm run check.

Dependencies / order

Prefer landing after #8 so latest-wins request ownership is established before refining the presentation of in-flight data.

Non-goals

• Changing GitHub billing permissions or aggregation.
• Preserving cached data indefinitely without a stale indication.
• Removing loading/progress feedback.
• Redesigning the entire operational rail.