How should I name my endpoint while adhering to the REST naming conventions?
REST doesn't care what spelling you use for your resource identifiers.
Think about how you would work through exercise in your web browser. You would fill out a form and submit the job; you'd get back some sort of receipt, which would include a link to status page. You could load/refresh the status page to see how things are going. If the server were taken down mid processing, that the job would fail, and the status page would be updated to reflect that. You might, for instance, find a form on that page that, when you submit it, resumes the job.
At no point in this flow do you, the client, need to figure out how to spell an identifier. You just follow links and fill in forms.
/a216fc62-6e0b-44da-8744-c7a8b4aae043 is a perfectly reasonable identifier for a resource that is going to handle a message.
For that matter, so is:
If you want the URI to be hackable, that's also fine -- but it's not a REST constraint. There are good reasons that you might want to make the URI hard to hack.
It's absolutely fine to POST a message to an endpoint, and have the endpoint figure out what to do based on the contents of the message body. So you can have a single endpoint that handles multiple kinds of message. This can be really convenient because the POST message will invalidate the representation of the resource cached by any participant that can read the request and response.
For example, since you know the "status page resource" will be changed by the instruction to resume the job, it may make sense to sent the resume message to that resource.