feat: order YAML output fields for Profile, RuleType, DataSource

[maryam22001]

Summary

When printing YAML output for profiles, rule types, and data sources, fields were ordered by protobuf field number rather than the canonical order defined in the project conventions. This PR adds a GetOrderedYamlFromProto helper in internal/util/ that marshals fields in the standard order (version → type → name → context → ...) for Profile, RuleType, and DataSource resources. Non-resource protos fall back to alphabetical order to avoid regressions.

Fixes #6428

Changes

• Added GetOrderedYamlFromProto helper in internal/util/yaml_order.go
• Updated cmd/cli/app/profile/get.go, ruletype/get.go, and datasource/get.go to use the new helper
• Added unit tests in internal/util/yaml_order_test.go
• Updated golden files to reflect correct field order

Testing

Unit tests

New tests added in internal/util/yaml_order_test.go:

export PATH=$HOME/go-install/go/bin:$PATH
go test ./internal/util/... -run "TestGetOrdered" -v

Test	Verifies
TestGetOrderedYamlFromProto_Profile	version → type → name are fields 1–3
TestGetOrderedYamlFromProto_RuleType	version → type → name are fields 1–3
TestGetOrderedYamlFromProto_DataSource	version → type → name are fields 1–3
TestGetOrderedYamlFromProto_ContextComesAfterName	context is field 4 when present
TestGetOrderedYamlFromProto_NonResourceFallsBackToAlpha	Non-resource protos still marshal without error
TestGetOrderedYamlFromProto_NilReturnsEmptyObject	nil input returns {}\n with no error

All 6 pass

Existing CLI golden file tests

Golden files updated to reflect the new field order:

go test ./cmd/cli/app/profile/... ./cmd/cli/app/ruletype/... ./cmd/cli/app/datasource/...

Updated files: list_profiles.yaml.golden, status_get.yaml.golden, status_list.yaml.golden, get_by_name.yaml.golden, list_populated.yaml.golden

Smoke test

make build
./bin/minder profile get    -n <name> -o yaml
./bin/minder ruletype get   -n <name> -o yaml
./bin/minder datasource get -n <name> -o yaml

Expected — every resource starts with version → type → name → context:

version: v1
type: profile
name: secret-scanning
context:
    project: my-project

Configuration

• Go 1.26.2
• No new dependencies introduced

[CLAassistant]

All committers have signed the CLA.

[evankanderson]

How will this scale as we add new fields to protocol buffers? I'm concerned that we'll end up forgetting to adjust the helpers, and end up omitting new fields in input and output.

Thinking out loud, it almost feels like we want to have a known set of document nodes which we serialize first, then serialize everything else alphabetically.

Looking at e.g. https://github.com/mindersec/minder-rules-and-profiles/blob/main/rule-types/github/branch_protection_lock_branch.yaml, it also seems like we serialize consistently within the def of the RuleType; ingest comes before eval comes before remediate comes before alert (which is the order that evaluation happens in).