[FEATURE]: Explicit opt-in plugin reload (CLI + server route) #44389

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

On 1.18.21 (stable/desktop) and on the current dev branch, applying plugin changes requires restarting the app, which kills unrelated long-running sessions. Recovery is blocked the same way: a failed plugin load stays cached for the process lifetime, so even fixing a broken plugin requires a restart.

We found related work: #34492 (watcher-based hot reload service), and #40825 / #35963 discussing watcher-triggered plugin reload on the next channel. This request is complementary: an explicit, deterministic trigger with documented session semantics — including npm-installed plugins, which live under the package cache (~/.cache/opencode/packages/) where file watching doesn't reach.

Proposal:

• CLI: opencode plugin reload [spec] (all plugins when omitted)
• Server: POST /plugin/reload (same behavior; lets desktop/TUI wire a button later)

Semantics:

1. Re-run the existing resolve → entry → compatibility pipeline for the target spec(s); import via a cache-busting query, falling back to importing from a unique temp copy if Bun ignores the query.
2. Swap the registered hooks atomically. Sessions started afterwards use the new version; already-running sessions keep their current hooks and toolset (documented, intentional — not a bug).
3. A failed reload keeps the previous hooks and surfaces via the existing error-reporting path. Module-scope side effects re-run per reload (dev-oriented trade-off).

Out of scope: mutating mid-session state of already-loaded plugin instances.

Happy to work on this behind a design review if maintainers agree with the scope; also glad to fold it into #34492 if you'd prefer one umbrella effort.