feat(ui): show how long each promotion step took - #6807

Description

Closes #6806

The promotion view shows a duration for the promotion as a whole, but individual steps show only their status. When a promotion is slow there is no way to tell which step accounted for it without inspecting the Promotion resource by hand.

This renders an elapsed time against each step:

• Finished step — measured from startedAt to finishedAt.
• Running step — counts up from startedAt on a one second tick, which is what distinguishes a step that is stuck from one that is merely slow.
• Not yet started — renders nothing.

The data was already present in status.stepExecutionMetadata and already exposed on the generated StepExecutionMetadata model, so there is no API, CRD or codegen change — this is purely presentational.

Completed promotion

git-clone took 2s; the two sub-second steps read <1s.

Running promotion — before / after

Before, a running promotion showed no timing at all (note the promotion-level duration row is absent entirely until the promotion is terminal):

After, the running step reports how long it has been waiting:

Live counter

The elapsed time on a running step ticks, then settles on its final value when the step reaches a terminal state:

Notes for reviewers

<1s rather than 0ms. API timestamps are RFC 3339 with second precision, so every sub-second step computes to exactly 0. Rendering that as 0ms would imply a precision the data does not have, so a zero duration renders as <1s. Non-zero sub-second values are still formatted exactly, in case finer-grained timestamps arrive later.

Clock skew. If the browser clock is behind the control plane, a running step's elapsed time would go negative; stepDurationMs returns null in that case so nothing is rendered rather than showing -3s.

Timer scope. The one second interval is owned by a small StepDuration component and only runs while a step is actually running, so finished steps do not hold a timer.

Out of scope. While testing this I noticed the promotion drawer does not refetch while it is open, so a step reaching a terminal state is only reflected after the view is reopened (the elapsed time itself ticks client-side regardless). That is pre-existing behaviour and untouched here — happy to open a separate issue for it.

Tested against a real promotion in a local kind cluster, including a step left running for 20+ minutes.

Checklist

Eligibility

• Linked to an existing issue with no blocking labels (kind/proposal, needs discussion, needs research, maintainer only, area/security, size/large, size/x-large, size/xx-large).
• Changes documentation only.
• Changes ten lines or fewer.

Quality

• Adds or updates corresponding tests.
• Adds or updates corresponding documentation.

AI Use Disclosure

This PR was written:

• By a human without AI assistance.
• By a human with AI assistance. A human has reviewed every line prior to opening the PR.
• By an AI with human supervision. A human has reviewed every line prior to opening the PR.
• Entirely by an AI. No human has reviewed this prior to opening the PR.

Sign-Off

All commits:

• Are signed off by their author (git commit -s) (required)
• Are cryptographically signed (git commit -S) (encouraged)

🤖 Generated with Claude Code