I don't like the disconnect between endpoints and deferred batches. It's gonna be rather annoying to verify that the data matches.
All the endpoints marked as DEFERRED need to be passed to the Job fetching the status, which then needs to fetch a status for each of them. But the additional info is passed along indexed by message_id (which isn't generic, BTW, and thus might cause issues when doing the same for FCM/whatever). 

The Job needs to iterate over every endpoint, since it needs to be make every endpoint gets a new status.  It also needs to iterate over the deferred batch, to check for overlap, extract that matching message IDs and request once per message ID the status of all relevant endpoints, and then loop again over all endpoints to assign the correct status.
That's an awful lot of house keeping :-/
IMHO, the info needed to fetch the deferred status should be attached to the endpoints themselves.

Needs updating?

what if the batch index doesn't exist? What if $this->statuses[$endpoint] is not an array?

Doesn't match the type of $this->statuses

I think the terminology here isn't quite right. For us it's a batch, but for the provider it should just be a message. There's no way to link multiple batches to the same notification on the provider side.
With this in mind, I think get_message_id() might be better.
Also, I don't think we can guarantee that message IDs are always integers. They might contain characters or they might be a uuid. So I think the method should return ?string

Why the string cast? What does changing NULL to "" solve here?

Ship It!