fix(governance): distinguish ephemeral tools from project dependencies

[SUaDtL]

Problem

$ca-add-dep currently applies whenever an agent needs to download and execute a third-party package, even when the package is an operator-approved, one-time developer analysis tool that will not be added to the project.

This conflates two different actions:

1. adopting or changing a project dependency, which must update and review the manifest and lockfile;
2. running an ephemeral developer tool such as jscpd to inspect the repository, with no project dependency or shipped artifact change.

The current behavior interrupted a duplicate-code investigation and insisted on project dependency review despite an explicit instruction that jscpd was not required by codeArbiter and must not be listed as a dependency.

Expected behavior

• $ca-add-dep governs dependencies that enter or change the project's dependency graph.
• An explicitly operator-approved, one-time developer tool can use a separate bounded tool-execution review or confirmation path.
• Ephemeral tooling must not modify package manifests or lockfiles unless the operator separately asks to adopt it.
• The execution path should still pin the exact package version, use the approved registry, isolate outputs/caches where practical, and report what ran.

Acceptance criteria

• Route project dependency adoption through $ca-add-dep unchanged.
• Do not describe or record an ephemeral analysis tool as a project dependency.
• Permit an operator-approved one-time tool invocation without manifest or lockfile changes.
• Add regression coverage for the distinction.

Reported by: SUaDtL@users.noreply.github.com

[SUaDtL]

Diagnosis from the 2026-07-20 backlog sprint:

• The manifest-based routing table is already narrow: $ca-add-dep is selected when a package manifest, lockfile, or base image changes.
• The public $ca-add-dep contract is broader than that rule. Its description says it applies "before any install runs," and its hard gate says no package may be installed before dependency review.
• There is no separate sanctioned command for an explicitly operator-approved, one-time executable tool. A wording-only exception inside $ca-add-dep would therefore recognize that the tool is not a dependency but leave the action unreachable under codeArbiter's command-only orchestration model.

Proposed feature contract: add a small $ca-run-tool <package@exact-version> -- <args> lane for ephemeral developer tooling.

• Require explicit operator approval before download or execution.
• Require an exact version and approved registry.
• Use isolated cache/output locations where practical.
• Do not modify project manifests, lockfiles, or shipped artifacts.
• Verify the repository dependency graph stayed unchanged.
• Report the exact command, resolved version, registry, cache/output locations, and result.
• Any request to adopt the package into the project still routes to $ca-add-dep unchanged.

This is a new public command, so the approved backlog sprint cannot author it without the feature spec gate. Leaving the issue open for that approval rather than implementing a semantically incomplete carve-out.