The render_color_index skips attributes with different types
and domains in order to give the proper order for the UI list. That
means it isn't with an index created while iterating over all attributes.

The most solid solution I could think of is exposing the name of
the default color attribute. It's "solid" because we always address
attributes by name internally. Doing something different is bound
to create problems. It's also aligned with the design in T98366 and
D15169.

Another option would be to change the way the "attribute index"
is incremented in Cycles. That would be a valid solution, but would
be more complex and annoying.

For consistency, I also exposed the name of the active color attribute
the same way, though it isn't necessary to fix this particular bug.

The properties aren't editable yet, that can come in 3.5 as part of D15169.