fix(pipeline-inspector): expose step name too

[phisco]

Description of your changes

Step name could also be useful here, we do have that information where the step metadata is setup, so it's trivial to add.

Given that the interface is new, I think we can ignore the breaking change and shift the numbering for now.

Fixes #

I have:

• Read and followed Crossplane's contribution process.
• Run earthly +reviewable to ensure this PR is ready for review.
• Added or updated unit tests.
• Linked a PR or a docs tracking issue to document this change.
• Added backport release-x.y labels to auto-backport this PR.

Need help with this checklist? See the cheat sheet.

[coderabbitai]

📝 Walkthrough

Walkthrough

A new step_name field is added to the StepMeta message in the pipeline inspector protocol buffer definition, with all subsequent field numbers renumbered accordingly to maintain proper field numbering sequences.

Changes

Cohort / File(s)	Summary
Protocol Buffer Definition apis/pipelineinspector/proto/v1alpha1/pipeline_inspector.proto	Added step_name string field to StepMeta message at field number 4; renumbered all existing fields (iteration, function_name, composition_name, composite_resource_uid, composite_resource_name, composite_resource_namespace, composite_resource_api_version, composite_resource_kind, timestamp) by incrementing their field numbers by one.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Possibly related PRs

• feat: pipeline inspector protobuf/gRPC definitions #908: Directly modifies the same StepMeta message structure in the pipeline inspector protobuf definition.

Suggested reviewers

• negz
• jbw976

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title clearly describes the main change: exposing the step name in the pipeline inspector proto, and stays well under the 72-character limit.
Description check	✅ Passed	The PR description is related to the changeset, explaining the rationale for adding step name exposure and addressing the breaking change to the interface numbering.
Breaking Changes	✅ Passed	The custom check targets non-generated .go files, but the breaking change is in a .proto file and its generated .pb.go outputs, which are explicitly excluded from scope.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Tip

🧪 Unit Test Generation v2 is now available!

We have significantly improved our unit test generation capabilities.

To enable: Add this to your .coderabbit.yaml configuration:

reviews:
  finishing_touches:
    unit_tests:
      enabled: true

Try it out by using the @coderabbitai generate unit tests command on your code files or under ✨ Finishing Touches on the walkthrough!

Have feedback? Share your thoughts on our Discord thread!

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@apis/pipelineinspector/proto/v1alpha1/pipeline_inspector.proto`:
- Around line 82-111: This change to StepMeta (adding string step_name = 4 and
shifting all subsequent tags) is a wire-format breaking change; ensure the PR
has the 'breaking-change' label applied and update PR description to explicitly
state this is intentional for the new pipeline inspector v1alpha1 and that
v1alpha1 may contain breaking changes without a migration path; reference the
proto message StepMeta and the new field step_name (tag 4) in the PR description
and any release notes so reviewers and downstream consumers are aware.

[ezgidemirel]

LGTM, thanks @phisco!

[jbw976]

Nice to see that the protobuf-schemas check caught all of these as breaking changes 🙌
https://github.com/crossplane/crossplane-runtime/actions/runs/21511425091/job/61979133723

but yeah, since this is unreleased these breaks are fine 😅