You've run into one of the rarer but more challenging problems - inheritance with an ObjC type that doesn't support concurrency well.
(I'm sure you've noticed that @unchecked is not used in this way, so skipping that.)
The immediate problem is that startLoading a) has no isolation but b) participates in concurrency via Task. When a type has no isolation, getting it to work with concurrency is much harder. But, in this case, all of the safe tools I can think of to fix this involve changing the definition of startLoading, which we cannot do, because that's not under our control.
Right now, you can make this work by marking MockURLProtocol as @unchecked Sendable. However, it does not look like URLProtocol is actually thread-safe? So, you'll have to be particularly careful with such an opt-out, as the inheritance opens the doors for even more traps that a regular unchecked type might.
(you may also want to keep your eye on the "isolated overloads" concept from [Prospective Vision] Improving the approachability of data-race safety, because I think it could help in this case)