tl/dr: it's okay to have the backend accept a user id as part of a zero-trust architecture. The more important part is that your
services must authenticate themselves to the backend, and the
appropriate parts of the backend should only accept requests from
your services (not from end-users). As a result your issue is trying
to use the auth token of an end-user for services that the end-user
isn't supposed to access directly. Let your services authenticate
themselves with the backend, and then it's perfectly fine to pass
along a user id.
Who is a "user"?
I think the key is that you're confusing who the "user" of some of your backend systems is.
This is most clear with your second example: deleting an inactive user. This is a system-only process. The user will never trigger this action themselves. The backend is the "user" performing the action, even though a user account is being affected. As a result it doesn't really make sense in the first place to be using the user's access token to delete the user. It's not like the user is ever going to be making these requests to the backend themselves. Indeed, user's should not be able to access these endpoints anyway. If somehow a user managed to access the backend to try to delete their account, their access token should be rejected - this endpoint is intended for system use only, (presumably) not for users to delete themselves. Therefore, by using the user's auth token to perform these system actions, you're authenticating as the wrong "person".
The situation is a bit more murky with your first example, because it is the user who makes an initial request which triggers the later actions. However, the overall situation seems is still the same anyway - a backend process is taking action on the user's data. The "user" of this system is not the actual end user, but is instead part of your own system. It just happens to be acting on behalf of your users.
In short, if you have backend services that are not meant to be invoked directly by users, then those services shouldn't accept the user's access token.
So what to do?
So how do you implement a zero-trust system? Naturally, the same way you are trying to do it - you're just authenticating as the wrong person. It's not the user that needs to authenticate itself to the backend, but rather it is whatever service is making use of the backend that needs to authenticate itself. This may or may not be with JWTs. It may be a simple matter of having an authentication token that only the "cron" service knows, and which it uses to authenticate itself with your backend. Those details are up to you.
However, I think that's the only real answer. These services need their own way to authenticate themselves with the relevant parts of your backend, and those parts of the backend should only accept requests from your authenticated services - not from end users with end-user JWTs. You'll obviously have to build the authentication method for your services in a way that covers issues with credential rotation if relevant. However, since you won't be using the user's password as part of that process, that won't be a concern.