Every safety analysis has a system boundary and a definition of "loss". In your example, the topmost system would also include you as a subsystem, and the loss you're trying to prevent is injury to yourself. Getting stranded is a hazard that could result in that loss. A mitigation could be to allow you to damage the vehicle subsystem to protect the person subsystem. A formal safety program would try to avoid process escapes such as overlooking a scenario like that. You might still decide not to design for it, but at least you consciously made that decision.

Identifying what a dangerous state is is usually left to the person writing the requirements. Often that's a completely different department from the engineers who implement them.

You are lucky to have someone write requirements who weights in these aspects. I have seen too many specs (this mostly happens in business software) where failures are knowingly or unknowingly ignored... because schedule.

I think failures should be designed for (or at least explicitly defined) even if the requirements do not include them.

I think that's a lot more common in software where safety matters. Often such software is developed according to some regulations like ISO26262.

Yes, I have to constantly remind other front-end developers that we don’t need to be pixel-perfect faithful to Zeplin or the story. It is more of a guide and you can always bring up any concerns you have or if you think something should be done differently and we can talk about it.