Component reports healthy when its dependencies are missing from disk

## Summary

`get_status` reports a component and all its resources as `healthy` when its `node_modules` is **absent from disk**. Health reflects whether the component loaded successfully at some point in the past, not whether it could load now — so a component that has lost its dependencies looks fine until something reloads it.

## Observed

On 5.1.x, a component whose `node_modules` had been destroyed days earlier (see #1973) reported:

```
('.name', 'healthy')
('.rest', 'healthy')
('.graphqlSchema', 'healthy')
('.jsResource', 'healthy')
('.authentication', 'healthy')
```

…with `availability: Available`, and every other component healthy too. On disk the component directory held only source — no dependency tree. The worker had the modules resident in memory from a startup that predated the loss, so it kept serving.

The moment the process restarted, the same component failed to load:

```
ResourceLoadError: Failed to load resource module .../dist/resources/.js
cause: Error: Cannot find module 'tweetnacl'
code: 'MODULE_NOT_FOUND'
```

Nothing in the status surface distinguished "running correctly" from "running on borrowed modules, will fail on next reload."

## Why it matters

This is the failure mode that turns a recoverable install problem into a latent one. An operator has no signal, monitoring has no signal, and the breakage materializes during an unrelated restart — at which point the cause is days old and the correlation is easy to miss. It also means a rolling restart can take out a component that has looked healthy for days.

## Suggested direction

Health for a component ought to reflect current loadability, not a cached load result. Options, roughly in increasing cost:

- Report a distinct state when a loaded component's on-disk dependencies are missing or don't match what was installed.
- Surface load-time module resolution failures as a component status, not only as log lines and unhandled rejections.
- Include a cheap dependency-presence check in the component health probe.

Any of these would have surfaced this within a health check instead of at the next restart.

Related: #1973 (the destructive install race), #1974 (why it never repaired itself).

---

🤖 Filed by Claude on behalf of @heskew

Start at the component health/status surface and the load or reload path described in the report; no specific files or tests are named. Compare cached health with dependency presence and module-resolution failures, and define the status behavior before implementing it. Done means missing node_modules or a load failure is visible through component status before a restart.

Written by the indexing model from the issue text.