Upgrading DSH silently disables version-mismatched profile plugins; the reason lives only on stderr

[Yebeimu]

Mounting a profile plugin at a version older than the running build results in phase=no-fiber disabled=true with no visible reason. The only evidence is one stderr line at startup:

dsh: disabling profile plugin row ... incompatible with dsh ...

Desktop users never see stderr.

What it looked like here. After upgrading desktop 0.2.1-rc.2 → 0.2.1-rc.3, a @deepseek-ai/dsh-hooks-claude-code 0.2.1-rc.2 row mounted in cordis.patch.yml stopped loading. Hooks stopped firing: a delete guard, a per-prompt routing note and a post-edit structure check all went quiet, with nothing in the UI. We noticed days later, by accident.

Why it was expensive to diagnose. di_loader_list reports phase=no-fiber disabled=true, which looks identical to a row disabled by config. Before reading stderr we tried three wrong explanations — absolute path instead of relative, moving the row to the end of the patch file, and removing the plugin's inject declaration. The third one broke the runtime (a service accessed without the declaration) and needed manual recovery.

Suggestion. Carry the reason into something queryable: a disabledReason field on the di_loader_list row would have ended this in one call, and the plugin inventory UI could render the same string.

Repro is mechanical: mount a plugin whose peer dependency version differs from the running build, restart, then read di_loader_list.