test(plugins): surface the admission refusal cause in the --yes-deps e2e test

An external verification run on Linux saw this test fail with a bare
`assert 'yes-deps-plugin' in []`: the install publishes into plugins/ and
a second PM admission transaction then enables it, and that admission
folds every exception into a refusal (exit 0, plugin installed but
disabled), so the assertion carried no clue about the environment-specific
cause. Verified locally that the mechanism reproduces the exact reported
shape: injecting a failure into the second sync_venv call (the enable
admission) yields the same bare failure while the first (publish) call
succeeds.

Carry the captured CLI output in the failure message so any machine that
reproduces this shows the `Enable ... refused: <cause>` line directly in
the pytest output.

tests/hermes_cli/test_plugin_dependency_consent.py

@@ -86,7 +86,13 @@ def test_yes_deps_carries_consent_through_non_interactive_install(admission_env,
 
     enabled = yaml.safe_load((home / 'config.yaml').read_text(encoding='utf-8'))['plugins']['enabled']
     output = capsys.readouterr().out
-    assert 'yes-deps-plugin' in enabled
+    # The install publishes into plugins/ and THEN a second PM admission transaction
+    # enables it; that admission catches every exception as a refusal, so an
+    # environment-sensitive failure there leaves the plugin installed-but-disabled
+    # with exit 0. Carry the CLI output in the failure message so the refusal's
+    # cause is visible on any machine instead of a bare `in []`.
+    assert 'yes-deps-plugin' in enabled, (
+        'install completed but the plugin was not enabled; CLI output:\n' + output)
     assert 'dependency install skipped (non-interactive)' not in output