Component list for UI Library should return auto-saved code components if any

This is rough POC but I think it solves the problem in 🐛 JS component slots don't appear in the preview canvas until published Active while allowing the client to only send status: true when adding the code component to the library.

the other thing this would allow is adding new props and slots after a component has been added to the library. there are probably other hurdles to overcome for this but this does allow the component list use the auto-save version of code components which would not affect currently published pages with published code components in them

Adding related issue. Added todos in there to point to this one.

Marking as stable blocker to remove the band-aid that currently covers up a bug.

🤔 I’m not sure I follow what’s going on here, what exactly is proposed, and why the draft MR’s direction is the right one.

AFAICT the draft MR is making the API returning the list of config entities of some type to no longer return what’s actually stored, but instead making it return the auto-saved (not really saved/live) config entity.

That means it becomes impossible to retrieve the non-auto-saved-but-actual config entity.

If I ignore that and try to follow this MR’s rationale then it seems like this argues 📌 Add a route for PATCHing both a config entity and its auto-saved version together Active was wrong, because when sending

PATCH 
status: true

, you’d want to use the auto-save entry, not the live data?

But if so, why is this MR only modifying ::list(), not ::get() and ::patch()?

Given the above, I don’t understand how this can be a bug report. The “list config entities of type” internal HTTP API works as intended? 🫣

Perhaps an issue update will illuminate me 😇

I will update the summary.