I also think something along these lines is the correct answer. It can be hard to pin down an exact metric because once you start optimizing for a metric it tends to not be a good measure of the original thing anymore. But in general I think it comes down to some measure of feature velocity combined with a counter metric on support/maintenance burden.

"Number of PRs merged" seems like "number of lines of code" wearing a trenchcoat, and I thought we all agreed back in the 90s that number of lines of code was a terrible measure of software productivity...

Feature velocity is another that's extremely easy to game. My company is trying this right now: instead of measuring PRs or lines of code, we are measuring number of customer facing features shipped. Well guess what? Everything is now a customer-facing feature. You did a big internal code refactor and data migration? Well guess what, that's a customer feature now because it unlocks future such and such. Deploy a new piece of infra? Customer feature. Dev tool improvement? Customer feature.

IMO trying to measure productivity gains is a fools' errand. The only thing that matters is CSAT, escaped defects, retention, cost per contact, and other metrics that measure actual business outcomes.