[BUG] Interactive session gives no startup notice when an installed plugin fails to load (dependency-unsatisfied); only /plugins shows it

Summary

When an installed plugin fails to load because a declared dependency is missing (dependency-unsatisfied), the interactive session gives no indication at startup. The startup screen renders normally, the plugin's commands and hooks are simply absent, and the only in-session surface that reports the failure is /plugins (Installed tab "Needs attention", Errors tab). A user who does not open /plugins learns the plugin is dead only by noticing its commands are gone.

Related but distinct: #72925 / #77801 (dependencies never resolve under --plugin-dir) and #49308 (headless plugin_errors docs). This report is about the interactive TUI's visibility of an already-detected load failure, not about resolution.

Version

Claude Code 2.1.261, macOS (Darwin 25.6.0).

Reproduction (isolated config dir, nothing touches the real one)

export CLAUDE_CONFIG_DIR=/tmp/plugin-lab            # fresh dir
claude plugin marketplace add <marketplace with plugin P declaring dependency D>
claude plugin install P@<mkt> --scope user --yes    # installs P + D ("+ 1 dependency: D")
claude plugin uninstall D@<mkt> --scope user        # rc 0, prints "warning: required by P" and proceeds
claude plugin list                                  # ✘ failed to load — Error: Dependency "D@<mkt>" is not installed — run `claude plugin install D@<mkt>` …
claude                                              # interactive session

Observed in the interactive session:

• Startup screen: welcome banner, the auto-mode notice, +2 more · /status. Nothing about a plugin failing to load.
• /plugins → Installed: a "Needs attention" group at the top, P Plugin · <mkt> · ✗ 1 error.
• /plugins → Errors (1): Dependency "D@<mkt>" is not installed — Install "D@<mkt>" or uninstall "P", with Enter to resolve.

Also observed (headless): claude -p prints nothing about the failure on stdout or stderr; claude plugin install P@<mkt> on the broken state exits 0 with a green success line.

Expected

A one-line notice at session start when any installed, enabled plugin failed to load, naming the plugin and pointing at /plugins (or folded into the +N more · /status notices so it is at least discoverable there). The detection and the repair already exist; only the unprompted announcement is missing.

Why it matters

A plugin's hooks are often the thing a user relies on for safety (permission walls, protected branches). When the plugin silently fails to load, those walls are gone and every normal-path surface reports health. The /plugins Errors tab is a good surface, but it is opt-in.