Tool files that fail to load crash the whole session/registry instead of being skipped

Title: Tool files that fail to load crash the whole session/registry instead of being skipped

Problem

When a project has a .opencode/tool/*.{js,ts} file that fails to load (for example, it imports a package that couldn't be installed), the failure dies the entire tool registry — and with it, every session run in that project. A single bad tool file makes the project unusable.

The tool registry in packages/opencode/src/tool/registry.ts globs {tool,tools}/*.{js,ts} and dynamically import()s each file (line ~195) with no error handling around the import. If the file throws (e.g. ResolveMessage: Cannot find package ...), the defect propagates and kills the registry's state effect, so the whole run fails. Any valid tool files in the same project never get a chance to load.

Repro

1. Create a project with a broken custom tool:

   // .opencode/tool/broken.ts
   import { tool } from "@opencode-ai/plugin"
   import { something } from "@opencode-ai/definitely-not-a-real-package"
   export default tool({ description: "broken", args: { x: tool.schema.string() }, async execute() { return "" } })
   

2. Open that project in the web UI and send any prompt.
3. Observed: the whole run dies with the ResolveMessage stack instead of answering.

Expected

A failing tool file should be skipped with a warning (log + UI), and the rest of the tool registry (including valid sibling tool files) should still load so the session can proceed.

Root cause

packages/opencode/src/tool/registry.ts — the import() inside the registry state builder has no try/catch; a single failing file dies the registry.

Notes

• I hit this using headless opencode via the web browser (the opencode serve API driven from a browser session); I did not test or investigate the TUI.
• The trigger here (an auto-installed tool dependency failing to resolve) is separate from the module-resolution mechanism itself; a missing/uninstallable package in any tool file reproduces it.
• Related: this is the repro used to hit the silently-dropped error in the companion issue about session run defects.