Expose sources as local actions underneath a "Browse" local task

Took an initial stab at implementing this. Seems to be straightforward, but we'll need some styling love because Claro assumes all local actions are, essentially "Add" buttons and styles them accordingly. Screenshot attached.

I don't agree with this change. We designed it to have both tabs at the top level.

I think we can solve some of the confusion by better naming the tabs, e.g. 'Browse modules' rather than just 'Browse'. I really don't think it makes sense to stick the recipes list, which is a curated list that we ship with, underneath the Browse heading just because they are both coming from PB. The recipes page as currently implemented is really not a *browsing* experience. I do agree that the whole thing is confusing, but I don't think this change makes it less confusing, it just buries some of the options even lower down and in a spot that doesn't make sense unless you are familiar with the PB architecture.

A lot of that can be fixed by making (a) the recipes/recommended plugin first in the order in config and (b) making "browse" the default action of the "Extend" menu. I'm sure you can do (a), but without code I'm not sure you can do (b).

I am thinking in terms of the overall architecture of the tabs now, I find it a confusing mess in Drupal CMS right now:

1. Recommended, first but not selected-by-default
2. List - ok there's a verb
3. Browse - ok, a verb, must be another version than list
4. Update - ok, a verb
5. Update Extensions - ok, umm, but why is that separate?
6. Uninstall - ok, a verb

IMHO, this would be a lot better with List, Browse, Update, Uninstall - with two browsers under browse, and two updates under update.

Even better might be:
- Install (Browse recipes, Browse modules, List (or even "Available"))
- Update (Update, Update Extensions)
- Uninstall

But that's a much larger / even core issue that cannot be decided. I'm still not clear on why there isn't like a "Drupal CMS" glue-type module for various tweaks and code that might make the product better. ¯\_(ツ)_/¯

There's not a glue module because it would have to be a last resort. We're really trying to lean on config, and recipes, as hard as we can. Maintaining a polyfill that has to deal with various moving targets is very hard, and potentially very fragile. Ask me how I know (one-word answer: Lightning). We've been able to accomplish a lot of these kinds of things, like tab alteration, with ECA.

I asked Ralf to comment his concerns about "everything-across-the-top" here, but I believe he added it here: https://www.drupal.org/project/project_browser/issues/3457966#comment-15... 🐛 Filter (categories) selection is leaking over into other sources Active

https://drupal.slack.com/archives/C01UHB4QG12/p1738768229634219

Postponing for the same reason as ✨ Update local task titles to match Drupal CMS changes Active - waiting for clear direction from a UX team who is working on this problem.