mcpx: degraded-scope log line says 'per-call' when the key is the directory #280

Problem

In this repo's pkgs/mcpx copy, the degraded-scope log line always claims the scope "degraded to per-call", even when it did not. An operator deciding whether callers share an instance is told the opposite of the truth.

Same defect as dezren39/darwin-nix#191 (fixed there by PR #396, merge commit 84b30a5), present here unfixed.

Evidence (verified on main 469c749)

• pkgs/mcpx/internal/daemon/registry.go is byte-identical to dezren39/nix's pre-fix version (verified with diff against 0c3a758^:pkgs/mcpx/internal/daemon/registry.go).

• Registry.keyFor (registry.go:1029) discards the resolved key when warning:

  key, degraded := scope.Key(cc)
  if degraded != "" {
      r.warnDegraded(p.Name(), scope, degraded) // key not passed
  }

• warnDegraded (registry.go:1054) hardcodes the destination and dedupes without the key:

  func (r *Registry) warnDegraded(server string, scope config.Scope, reason string) {
      k := server + "\x00" + string(scope) + "\x00" + reason
      ...
      r.logf("server %q: scope %q degraded to per-call: %s", server, scope, reason)
  }

• But Scope.Key (pkgs/mcpx/internal/config/scope.go:58) only falls back to call:<id> for some scopes:

  • repo / worktree with an unreadable or non-git cwd degrade to cwd:<dir> — one instance per directory, shared by every caller in it
  • worktree with no worktree degrades to cwd:<dir>
  • parent-session with no parent id degrades to session:<id>
  • only e.g. session with no session id (and the generic fallback) degrade to call:<id>

  So for the common repo/worktree cases the log line claims per-call isolation while callers in the same directory actually share one instance.

• The dedup is also wrong: because the dedup key omits the resolved key, the same reason resolving to a different directory never warns again, even though it is a different (non-)sharing situation.

• pkgs/mcpx/internal/daemon/registry_degraded_test.go does not exist in this repo.

Why it matters

The warning exists so silent degradation looks like a configuration problem, not a performance mystery. Naming the wrong destination misleads exactly that diagnosis: "per-call" suggests cold-start cost and isolation; cwd: means shared state across callers in a directory.

Suggested fix (mirrors dezren39/nix PR #396)

• Pass the resolved key from keyFor into warnDegraded; log degraded to %s with that key.
• Include the resolved key in the once-only dedup key, so the same reason in a different directory warns again.
• Port registry_degraded_test.go from dezren39/nix (module path is identical: github.com/dezren39/mcpx), re-pointing its issue reference to this issue: naming matrix for the cwd / session / per-call fallbacks, plus the per-key dedup test.

Acceptance criteria

• For a worktree scope degrading in a non-worktree directory, the log line names cwd:<dir>, not per-call
• For a parent-session scope degrading to the session id, the line names session:<id>
• A genuinely per-call fallback still names call:<id>
• The same reason resolving to two different directories warns twice (once per key); the same key+reason warns once
• New regression tests cover the above and fail on the pre-fix code; go test ./internal/daemon/ ./internal/config/ passes