Not only this, but it's also extended in a bad way, see SpecialQuestionGameUpload: the constructor has

public function __construct( $request = null ) {
	SpecialPage::__construct( 'QuestionGameUpload', 'upload', false );
}

it's not using parent::__construct because the parent doesn't allow specifying another page name, nor making the page unlisted (which makes sense, I mean, you shouldn't be subclassing SpecialUpload!). In turn, this causes the parent constructor to be skipped, and the services aren't initialized, which throws an exception as soon as you try calling basically any method.

I feel inclined to point out that the ugliness in Social-Tools predates MW's stable interface policy by years. :) As always, better solutions are more than welcome.

Also, MediaWiki-extensions-MultiUpload is hopelessly broken anyway (since...MW 1.32? or earlier).

The ideal solution would be, as in most similar cases, extracting the business logic from SpecialUpload into a separate class that any special page can use. That would, of course, take a fair amount of effort.

Converting SpecialUpload into SpecialUploadBase, with SpecialUpload as a very lightweight subclass, would be an easy way to support sane inheritance in extensions with minimal effort.

In T265300#6636964, @ashley wrote:

Also, MediaWiki-extensions-MultiUpload is hopelessly broken anyway (since...MW 1.32? or earlier).

I haven't tested it myself, but we have anecdotal accounts of it not working on our MW 1.31 wiki either.