dsh-doctor — surface the patch failures that boot silently

[asdf17128]

While exploring the layering model I hit two failure modes that boot cleanly with exit code 0:

1. An id-targeted patch replaces an entry's whole config.

- id: session-title
  config:
    fallbackMaxWords: 12

session-title also ships fallbackMaxBytes: 40 and maxTitleBytes: 80. After this patch both are gone from the tree that boots. docs/architecture.md covers it in one clause — "restate unchanged fields" — but nothing warns at runtime, and --dump-config before/after is the only way to notice.

2. A patch targeting an unknown entry id is inert.

Typo agent-default-model as agent-defualt-model and you get one stderr line, then a normal boot with exit code 0. Launching the Web UI, you never see it — the customization just silently doesn't apply.

Both are easy to hit after an upgrade renames an entry id, and neither surfaces until behaviour drifts weeks later.

I wrote a read-only checker for them:

npx github:asdf17128/dsh-doctor

It diffs --dump-config against --dump-default-config, so every finding is attributable to the user's own patch layer rather than an upstream default.

• --fix restates the dropped fields — textual edit inside that one config: block, .bak first, so comments and !!js expressions survive
• --explain groups the ~130-entry tree by area and reports disabled: !!js … entries as conditional rather than collapsing them to a boolean
• It also flags tool-name collisions before boot: the registry rejects a duplicate name and the boot audit escalates it to a startup failure, but the error names the tool and not the two packages fighting over it

Zero dependencies, never boots a plugin, never evaluates !!js expressions.

Repo: https://github.com/asdf17128/dsh-doctor

Happy to add rules for other silent-failure cases — reproductions welcome. And if either of these is considered a bug rather than intended strictness, I'd rather see dsh warn natively and delete my check.