facade: refactor facade_phase to return the group itself so that celery can properly convert things into a chord

[MoralCode]

Description
While I haven't been certain that I can see the facade recollection issue locally, this change allowed me to successfully find facade_task_success_util via a flower task search in my local instance, meaning the tasks that were not running are now running again,

The thing that helped me get through this issue was this analysis from GPT5:

I traced the facade orchestration. The issue is how the facade phase is chained: your facade_phase returns a chain that ends with a group, and then the outer routine chains the “success” util after that. In Celery, when you want to run something after a group completes, you must form a chord (e.g., group(...) | next_task). A nested chain that returns only a group won’t implicitly convert to a chord, so the subsequent facade_task_success_util never fires.

Notes for Reviewers
In doing this refactor, I didnt see any other uses of facade_phase besides in build_facade_repo_collect_request, so it doesnt seem like the specific return type here is being super heavily relied on (although maybe thats due to an unwritten convention as noted in #3272)

Signed commits

• Yes, I signed my commits.

[Ulincsys]

Is there a particular reason to keep the list if we are just going to peek the first item from it on return?

[MoralCode]

i only did this to preserve the log statement. i guess if the print statement can handle the list of objects just fine, it should be fine to just throw the object at it.

[MoralCode]

thanks for calling me out on my addition of tech debt lol - this probably isnt necessary, i think i was just like "eh whatever it works" when i wrote it and forgot to revisit

[MoralCode]

oh fun, i guess one of my rebases or amends must have stripped out the DCO...

[sgoggins]

This is looking useful!!!