Consider warning on unexpected I/O errors

"io" covers unexpected errors (e.g. permission denied, disk errors) that are distinct from a simple missing file ("path"). Silently skipping them makes disk-level problems invisible to the operator. A "warn" diagnostic here would preserve the non-fatal startup behaviour while still surfacing the anomaly in logs:

This is a comment left during a code review.
Path: src/plugins/discovery.ts
Line: 479-482

Comment:
**Consider warning on unexpected I/O errors**

`"io"` covers unexpected errors (e.g. permission denied, disk errors) that are distinct from a simple missing file (`"path"`). Silently skipping them makes disk-level problems invisible to the operator. A `"warn"` diagnostic here would preserve the non-fatal startup behaviour while still surfacing the anomaly in logs:

```suggestion
    if (opened.reason === "path") {
      // File missing (ENOENT/ENOTDIR/ELOOP) — skip silently, not a security violation.
      return null;
    }
    if (opened.reason === "io") {
      params.diagnostics.push({
        level: "warn",
        message: `extension entry could not be read (I/O error): ${params.entryPath}`,
        source: params.sourceLabel,
      });
      return null;
    }
```

How can I resolve this? If you propose a fix, please make it concise.

Preserve diagnostics for I/O failures opening plugin entries

openVerifiedFileSync() intentionally distinguishes missing paths from real filesystem failures by returning reason: "io" for cases like EACCES/EMFILE (src/infra/safe-open-sync.ts:84-88), but this branch now collapses those into a silent null. Both discovery callers treat null as “skip this plugin” (src/plugins/discovery.ts:564-595 and 694-725), so a configured plugin package with an unreadable entry file now just disappears with no diagnostic at all. The ENOENT fix makes sense, but swallowing non-path errors regresses debuggability for genuine startup failures.

Useful? React with 👍 / 👎.

Fixed in a87ccfa. Now handles all 3 reasons explicitly: path → silent null (ENOENT), io → warn diagnostic (EACCES/EMFILE surfaced without abort), validation → error diagnostic (security). I/O failures are no longer invisible.

Restrict missing-entry suppression to partially installed bundles

This return null also applies when the user explicitly points OpenClaw at a package directory via extraPaths/config. In that path, if package.json declares openclaw.extensions but the built entry file is missing, discoverFromPath() now returns with no candidates and no error (src/plugins/discovery.ts:694-725), which turns a broken third-party package or typo into a silent no-op. The original Arch/AUR case is about partially installed bundled plugins, but applying the same ENOENT suppression to all package origins hides actionable misconfiguration elsewhere.

Useful? React with 👍 / 👎.

Restrict missing-entry suppression to ENOENT

opened.reason === "path" is broader than the missing-file case this fix is targeting: openVerifiedFileSync() also maps ENOTDIR and ELOOP into "path" (src/infra/safe-open-sync.ts:17-20,84-88). With this branch, a package entry like ./dist/index.js now disappears silently if dist is accidentally a file or a symlink loop, instead of producing any diagnostic. That regresses debuggability for malformed packages; only plain ENOENT should be skipped here.

Useful? React with 👍 / 👎.