Failed `postremove` leaves the shell inside the moved trash directory

[gpu004]

What I observed

When a postremove hook fails while I remove the current child through the zsh wrapper, the child is moved to trash but the wrapper leaves my shell inside that moved directory.

Reproduction

cargo build --locked
probe=$(mktemp -d /tmp/rift-postremove.XXXXXX)
mkdir -p "$probe/source" "$probe/home"

RIFT_BIN="$PWD/target/debug/rift" PROBE="$probe" HOME="$probe/home" zsh -f <<'ZSH'
"$RIFT_BIN" init --here "$PROBE/source"
child=$("$RIFT_BIN" create "$PROBE/source" --name child)
cat > "$child/.rift.toml" <<'TOML'
version = 1
[[hooks.postremove]]
run = "exit 23"
TOML

eval "$("$RIFT_BIN" shell-init zsh)"
cd "$child"
printf 'before logical=%s physical=%s\n' "$PWD" "$(pwd -P)"
rift remove
printf 'status=%s after logical=%s physical=%s\n' "$?" "$PWD" "$(pwd -P)"
ZSH

The wrapper exits 1. $PWD still contains the old child path, while pwd -P points into .trash/<id>-child. The old child path is gone, the active child row is gone, and a trash row exists.

Expected

If removal has already moved the current directory, the shell wrapper leaves the shell at a valid active path even when postremove fails.

Actual

The shell remains attached to the moved trash directory, with a stale logical $PWD.

I do not know whether a failed postremove hook is intended to roll back removal. This report is limited to the shell state after the failed command.

Environment

• Rift commit 757a22cb247f
• zsh on macOS 26.6.2, arm64, APFS