Name the dev-link authorization when it is the thing that failed

Validating /etc/omarchy.conf walks its parent chain to /, and that walk leaves
its own subject behind in the global failure_context. The comparison that
follows -- the one deciding whether the authorization actually names this
checkout -- sets no context of its own, so an unauthorized development tree
refused with:

  refusing to publish: directory / (must be root-owned and not group- or
  world-writable) failed validation

naming a directory that had just passed, and pointing the reader at a
filesystem problem that is not there. Seen on a worker VM running an
unauthorized checkout, where / is 0555 root-owned.

The hint line underneath was already right, which is what kept this from being
worse. Restore the context before the comparison so the first line agrees with
it, and assert both halves: that the refusal names the authorization, and that
it does not blame the root directory.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0115LngksSpXLD9NSXBEP3ki

test/shell.d/plymouth-set-test.sh

@@ -504,6 +504,13 @@ status=$?
 
 (( status != 0 )) || fail "a stale dev-link authorization is rejected"
 [[ $(cat "$theme/bullet.png") == 'old plymouth bullet.png' ]] || fail "a stale dev-link authorization leaves the live theme unchanged"
+# The refusal has to name the authorization. Validating /etc/omarchy.conf walks
+# its parents and leaves that walk's subject in failure_context, so without
+# restoring ours this refuses with "directory / must be root-owned and not
+# group- or world-writable" -- accusing a directory that passed and pointing the
+# reader at a filesystem problem that does not exist.
+[[ $output == *"$omarchy_conf"* ]] || fail "a stale dev-link refusal names the authorization it rejected" "$output"
+[[ $output != *"directory / "* ]] || fail "a stale dev-link refusal does not blame the root directory" "$output"
 assert_no_temporary_files "$fake_root"
 
 setup_run