Track existing semgrep architecture-lint blockers in internal/cli

[proboscis]

Summary

The repo's semgrep architecture-lint hook is currently blocked by pre-existing violations in internal/cli/, which prevents normal commits even when a change does not introduce any new boundary violations.

Current blockers seen from the hook output:

• internal/cli/master_worker.go

  • semgrep.cli-no-daemon-import
  • CLI imports internal/daemon directly.

• internal/cli/remote_control.go

  • semgrep.no-raw-exec-in-boundary-layers
  • raw exec.Command in a CLI boundary file.
  • semgrep.cli-no-worktree-fs-check-incremental
  • direct os.Stat worktree checks in CLI.
  • semgrep.cli-no-opencode-client
  • CLI constructs agent.NewOpenCodeClient(...) directly.
  • semgrep.cli-no-multiplexer-direct
  • CLI sends tmux/zellij keys directly.

Why this matters

These are existing baseline violations, but the pre-commit hook runs across the whole boundary layer:

commit -> semgrep hook -> existing findings in unrelated files -> commit blocked

That means:

• unrelated changes need --no-verify to land
• architecture lint loses signal because developers get blocked by old debt instead of new regressions
• boundary rules in AGENTS.md / semgrep are harder to enforce incrementally

Desired outcome

Pick one of these approaches and make it explicit:

1. Fix the existing violations in master_worker.go and remote_control.go.
2. Move them behind daemon / orchapi APIs so CLI no longer crosses the boundary directly.
3. If immediate cleanup is too large, add a deliberate temporary baseline/allowlist strategy so the hook blocks only new violations until the debt is retired.

Acceptance criteria

• make lint does not fail solely because of the known internal/cli/ baseline violations.
• Commits for unrelated changes do not require --no-verify.
• The long-term boundary remains: CLI should use daemon APIs rather than direct daemon/process/multiplexer/OpenCode/file-system operations.