The following is my understanding of the route you could take if you don't want to use the XML option proposed by PMH_UK above. BOINC projects all have similar settings for computing preferences and your client gets the most recent revision from any projects you've attached to the client. There are also project preferences unique to that project. See lists of both here but that page doesn't quite match up with preferences on WCG.

So you would want your computing preferences set regarding the maximum cores BOINC should use no matter the project. On WCG this is done using the "custom profile" option when viewing one of your Device Profiles
and is in the Advanced Options section. But then in per-project settings you'd need to adjust what most projects refer to as "resource share" but which WCG refers to as "project weight". The default is 100 and this scales the CPU time proportionally across however many cores you allocate.

Because WCG is a bit of a "meta" project with its own project limits, I would set "resource share" on your other projects and then set all preferences at WCG last including its "project weight". So if you want LHC to get 25% of the time on your cores you can have it use the default of 100 for the share, then Rosetta and WCG should both be set to 150 each. So you see that LHC with 100 is 25% of the overall 400 amongst them all.

Finally there is a "switch between tasks" or "switch between applications" as WCG calls it. That determines how often work on one project is suspended to start putting computing time toward the others. So an hour toward LHC, then switch to Rosetta for an hour, then WCG for an hour, and so on until in an eight hour period you have two hours on LHC and three on each of Rosetta and WCG.

But this is in the Default profile setting.
Maybe i need to make these in the "Home" setting?

The missing element is time. I think the way to go for your requirement is setting the resource share to 100 for each project and it will eventually settle down to giving each project an equal share but that can take weeks (WCG is taking all the cores because it is seen as being behind in getting its share and so it’s playing catch up).

One thing you can do to speed up the process is to go into computing options and setting the half life from its default of 10 to 1. This reduces the number of days processing that is taken into account and therefore makes it quicker to reach a balance.

The problem with setting the max concurrent in the app config files comes when one of the projects goes quiet (as Rosetta and CPDN are now). Because the other projects have a fixed max they cannot take up the slack and you end up with idle cores.

It looks like there is an option in the cc_config.xml file that relates to this.

<rec_half_life_days>10.000000</rec_half_life_days>

Indeed the default value is 10 and so Bryn Mawr is recommending it be set to 1. The description in the documentation for it is "A project's scheduling priority is determined by its estimated credit in the last X days. Default is 10; set it larger if you run long high-priority jobs."