omz reload fails with 127 when $commands[zsh] points to a deleted zsh

Describe the bug

Since #13922, _omz::reload and the post-update restart replace a non-absolute ZSH_ARGZERO with $commands[zsh] and exec that path. $commands is backed by zsh's command hash table, and a hash entry is not invalidated when its target file is deleted. If the cached zsh path no longer exists, reload execs a dead path and fails with no such file or directory, exit status 127. A bare exec zsh does not have this problem: zsh detects the dangling hash entry and re-searches $PATH.

Steps to reproduce (zsh 5.9; any OS)

mkdir -p /tmp/a /tmp/b
printf '#!/bin/sh\necho A\n' > /tmp/a/zsh; printf '#!/bin/sh\necho B\n' > /tmp/b/zsh
chmod +x /tmp/a/zsh /tmp/b/zsh
export PATH=/tmp/a:/tmp/b:$PATH
echo $commands[zsh]    # /tmp/a/zsh — hash entry cached
rm /tmp/a/zsh
echo $+commands[zsh]   # still 1, value still /tmp/a/zsh
exec "$commands[zsh]"  # zsh: no such file or directory: /tmp/a/zsh (127)

Running omz reload in that state (ZSH_ARGZERO=zsh, -zsh or a relative path) hits the last line.

Expected behavior

Reload execs a zsh resolvable on the current $PATH (what bare exec zsh finds), not a cached path that no longer exists.

Zsh version

5.9 (affected since #13922 on master)

Additional context

Found in the #13922 post-merge discussion: https://github.com/ohmyzsh/ohmyzsh/pull/13922#issuecomment-5697670970. Fix incoming: use the bare command name and let exec do the $PATH lookup, which re-validates the hash.

AI disclosure: this report was prepared with AI coding agents, reviewed by me.