What Problem This Solves

Skill Workshop can be enabled, loaded, and auto-capturing proposals while the skill_workshop tool is silently hidden from agent sessions because the effective tool policy excludes it (e.g. tools.profile: "coding" without group:plugins). Every inspection surface (openclaw plugins list --enabled, openclaw plugins inspect skill-workshop) reported the plugin healthy, so operators debugged this as a plugin registration bug instead of a one-line policy grant.

Closes #87570.

Why This Change Was Made

• Shared availability resolver (src/skills/workshop/tool-policy-diagnostic.ts): resolveSkillWorkshopToolPolicyAvailability runs the real effective-tool-policy pipeline with a lightweight skill_workshop probe (constructing the actual tool has storage/config side effects irrelevant to policy resolution) and, when the tool is excluded, attributes the excluding layer precisely — global/agent/provider profile, allowlist, denylist — including shadowing (an agent-level alsoAllow recommendation when agent config owns the effective policy, not a global one that would be ignored).
• openclaw plugins inspect skill-workshop now prints the excluding policy source and the exact grant to add (e.g. tools.profile: "messaging" does not include "skill_workshop" / fix: Add tools.alsoAllow: ["skill_workshop"]).
• openclaw doctor gains core/doctor/skill-workshop-tool-policy in the real doctor contribution path (the interrupted first pass registered it constructor-only, which doctor --lint flagged as an unknown check — fixed and covered). The wiring refactor also deduplicates two pre-existing copy-paste health runners into one runCoreHealthFindingNote helper.
• /learn now reuses the shared resolver instead of composing tool policy itself — the follow-up flagged in the /learn PR review, landed here.
• Provenance hook: applyToolPolicyPipeline accepts an optional onFilter callback (ToolPolicyFilterEvent) so diagnostics can see which step excluded the tool; no policy behavior change.
• UI empty-state hint deliberately skipped: the proposal gateway data carries no effective-policy verdict, and computing it client-side would duplicate server policy logic — needs a new gateway surface, follow-up territory.

User Impact

Operators hitting the "plugin healthy but tool missing" trap get an actionable answer at both surfaces they actually check, naming the excluding config layer and the exact alsoAllow grant. Diagnosis only — no tool-policy behavior, defaults, or profiles change. Docs: troubleshooting note in skill-workshop.

Evidence

• Focused Testbox suites green: tool-policy-diagnostic.test.ts, doctor-core-checks.test.ts, doctor-health-contributions.test.ts, plugins-cli.list.test.ts, commands-learn.test.ts (139 tests in the implementation pass, re-run on the final tree).
• Full remote check:changed passed; core + core-test typechecks passed; git diff --check clean.
• Black-box proof: inspect output, normal doctor, doctor --lint, coding-profile negative case, disabled-autonomy negative case, and shadowed-grant case all verified against a real config.
• Structured second-model review (Codex, gpt-5.5): round one found the shadowed-alsoAllow misattribution (fixed); final round clean on the full branch diff.
• Release-note context: user-facing feat — plugins inspect and doctor now explain when tool policy hides the Skill Workshop tool and name the exact grant to add.