samuel doctor: doesn't actually check plugin health despite help text

[ar4mirez]

Problem

samuel doctor's help text and the README advertise "framework + plugin health" (cmd/samuel doctor's short description, README.md tour section). But when run in a project with installed plugins, doctor only checks framework health — builtins and project layout. It has no awareness of installed plugins.

Repro

$ samuel install actix-web --allow-unsigned
✓ Installed actix-web@1.0.0 (skill)

$ samuel ls
Installed plugins (1)
  actix-web                      1.0.0      skill

$ samuel doctor
Samuel doctor
  ✓ samuel-builtins — samuel builtins 2.0.0-rc.6 synced
  ✓ project-layout — .samuel/ layout intact

Summary: 2 passed, 0 failed, 0 fixable, 0 fixed

Doctor would not detect:

• A plugin whose files were modified after install (drift from the lockfile digest).
• A plugin whose samuel-plugin.toml manifest is missing or corrupt.
• A plugin whose lockfile entry was tampered with (or removed).
• A [[plugins]] entry in samuel.toml with no corresponding .samuel/plugins/<name>/ dir.

Each of those is the kind of thing "verify plugin health" implies the command checks.

Suggested fix

Add a plugins check to the doctor pipeline that:

1. Loads samuel.lock and iterates installed plugins.
2. For each, confirms the on-disk directory exists.
3. Recomputes the digest and compares against the lockfile entry.
4. Validates the manifest (samuel-plugin.toml) parses and matches the lockfile's kind.
5. Reports each plugin as ✓ <name>@<version> — signed/healthy/... or ✗ <name> — drifted/missing/....

Optional follow-on: --fixable could re-install drifted plugins from the registry.

Severity

Medium. Functional install still works; this is unmet advertised functionality. The doctor command was the user's first line of defense against quiet corruption; today it gives a false sense of security.

Found during

rc.6 manual testing — Test 3 of the post-install validation sequence.

[ar4mirez]

Fixed in 0869269 — shipping as v2.0.0-rc.11.

`checkInstalledPlugins` walks every `samuel.lock` entry and produces one `plugin:` check per installed plugin. Each plugin is verified in order against four invariants; first failure wins so the user sees the most actionable hint:

1. `.samuel/plugins//` exists on disk
2. `samuel-plugin.toml` parses
3. Manifest `name` / `version` / `kind` match the lockfile entry
4. Per-kind required artifact is present:
   • skill → `SKILL.md`
   • wasm → `manifest.wasm.module` (default `plugin.wasm`)
   • oci → `manifest.oci.image` non-empty

Out of scope (deferred to a follow-on): digest verification. Installs don't yet write `LockedPlugin.Digest`, so there's nothing to compare against. Once installs start recording the digest, doctor can add a content-drift check trivially.

Verified end-to-end on tetris:

Scenario	Output
Healthy install	`✓ plugin:actix-web — 1.0.0 (skill) — manifest + artifact intact`
`rm SKILL.md`	`✗ plugin:actix-web — SKILL.md missing from .../actix-web` + fix hint
`rm -rf .samuel/plugins/actix-web`	`✗ plugin:actix-web — installed dir missing — samuel.lock claims it, but .../actix-web is gone` + fix hint
Tampered manifest (`version = "9.9.9"` vs lockfile `1.0.0`)	`✗ plugin:foo — manifest drift: lockfile @1.0.0 but manifest @9.9.9`
No plugins installed	No `plugin:*` checks (silent — correct)

Each failure carries a `fix: samuel install --force` hint, so doctor's existing "fixable" counter naturally reflects what the user can recover.

Five regression tests cover each scenario in `init_test.go`:

• `TestDoctor_PluginHealth_HappyPath`
• `TestDoctor_PluginHealth_MissingDir`
• `TestDoctor_PluginHealth_ManifestDrift`
• `TestDoctor_PluginHealth_MissingSkillFile`
• `TestDoctor_PluginHealth_NoLockfileNoChecks`