feat: add trust-aware config diagnostics

[oratis]

Summary

• track leaf-level JSON Pointer provenance across user, project, local, and explicit override settings
• move directory trust into core and apply it consistently in every app-server host
• prevent untrusted project settings from redirecting providers or widening model cost, permissions, sandbox, environment, hooks, MCP, worktree, update, and executable configuration
• expose value-free config/diagnostics over the versioned protocol with capability negotiation
• reject malformed/prototype-polluting settings and trust files

Validation

• pnpm format:check
• pnpm lint (one pre-existing warning)
• pnpm typecheck
• pnpm test (973 passed, 12 skipped)
• pnpm build
• pnpm docs:check
• built and syntax-checked the desktop sidecar and VS Code app-server CJS bundles
• executed initialize and config diagnostics handshakes against both bundled runtimes
• packaged VSIX successfully after the protocol change

Stack

Depends on #196.

[oratis]

Review: approved ✅ — this is the second-most security-significant PR in the stack

The core property: an untrusted project's settings can no longer redirect the provider or widen policy. The listed surface — provider/base-URL, model cost, permissions, sandbox, environment, hooks, MCP, worktree, update, executable config — is the right list, and it's the complete list of ways a hostile .deepcode/settings.json could have escalated. Provider redirection is the sharpest one: it turns "open a repo" into "send your prompts and key to an attacker's endpoint".

What I checked

• Trust moved into core and applied consistently in every app-server host. Trust checks that live in each client are trust checks that one client forgets — that's the same failure shape as the Runtime safety: mandatory policy and real cancellation #181 gate bypass, so centralizing it is the structural fix, not just a tidy-up.
• Leaf-level JSON Pointer provenance across user/project/local/override layers. Per-leaf rather than per-file is what allows a project to keep contributing benign settings while specific dangerous leaves are refused — otherwise the only options are "trust everything" or "ignore the file".
• Explicit override (--settings) is treated as trusted. Consistent with how that flag already behaves — it's a deliberate user choice made on the command line, not content discovered inside a repo.
• config/diagnostics is value-free and capability-negotiated. Correct: a diagnostics endpoint that echoed values would itself become the exfiltration path for the secrets this PR is protecting. Reporting provenance without values is exactly right.
• Prototype-pollution rejection on settings and trust files. __proto__/constructor keys in parsed JSON are a real escalation route in a config merger, and merging is precisely what this code does.

Validation: CI green; full suite green locally at the stack tip.