shell_safety: "Override: /set yolo_mode true" hint is a guaranteed no-op

Bug

shell_safety/register_callbacks.py — Gate at lines 105–108, messages at lines 126, 167, 187.

The callback only ever runs while get_yolo_mode() is already true (it returns None silently otherwise, line 107). Yet every blocked-command error message tells the user/agent to "Override: /set yolo_mode true or /set safety_permission_level {risk}".

An agent that hits a blocked command reads the first half of the hint, runs /set yolo_mode true (a guaranteed no-op), and wastes a turn. The exception path (line 187) is worse: it declares risk HIGH and suggests /set safety_permission_level high — i.e. exactly the setting that would allow the failing command.

Suggested fix

Drop the yolo_mode alternative from all three messages and keep only /set safety_permission_level <needed>. Consider choosing the suggested level more carefully on the error path (suggesting "high" as the override for a command the assessor could not evaluate is arguing the LLM disagrees with a fail-closed policy).

Start in shell_safety/register_callbacks.py at the gate around lines 105–108 and the messages around lines 126, 167, and 187. Update the hints so they no longer suggest the no-op yolo_mode override, and review the exception-path risk suggestion against the fail-closed behavior described in the issue. Done means all three messages give actionable safety_permission_level guidance.