I can't disagree with Gary Myers who said in the comments that this wasn't a straightforward solution. It's not that I didn't have reservations about implementing a GROUP BY that did nothing. In fact, when I had to explain it to two different developers I kind of knew I went down the wrong path.
Some of the alternate workarounds and their results were:
1. Gary and Anonymous suggested that I duplicate the business logic of some_funky_package_call in the query itself. Good thought, but because some_funky_package_call is used in multiple places, I wouldn't want to have to go back and fix multiple queries when the underlying logic of some_funky_package_call changed. In circumstances where some_funky_package_call was only used for this query, that method would work.
2. Craig Martin had two suggestions for me. The first one I tried was using the +MATERIALIZE hint. This seemed like the easiest to implement, but resulted in an error I've never seen:
ERROR at line 6: ORA-12840: cannot access a remote table after parallel/insert direct load txn ORA-06512: at "MYUSER.SOME_FUNKY_PACKAGE_CALL", line 24 ORA-06512: at line 1
Oh well, the easiest solution isn't necessarily the best anyway.
3. Then I tried Craig's second solution; use ROWNUM to force Oracle to evaluate the inline view first. This actually worked very well. Both the trace and the elapsed time were at least twice as good as my GROUP BY query.
So a big THANK YOU to Gary, Craig, and Anonymous for helping me out. I now have a more straightforward solution that works faster than my original "fix".