Assess removing unused fstools ShellTool

Problem

engine/adapter/fstools.ShellTool is a synchronous reference implementation of the Shell tool, but no shipped mecatl composition path uses it. Production catalog assembly registers agent.NewShellTool() because that implementation owns the current background:true / ShellStatus integration.

The only in-repository uses of fstools.ShellTool are its internal/adapter/tools re-export and tests. Its stated use case is a hypothetical external engine embedding that wants command execution but not the agent-loop implementation. We have no concrete consumer for that shape.

This leaves two near-duplicate foreground Shell implementations:

• engine/adapter/fstools/bash.go
• engine/agent/bashtool.go

They must remain behaviorally aligned for parsing, temporary scopes, output shaping, compatibility feedback, and errors, while only the agent implementation provides background jobs.

History

This appears to be residual architecture from the foreground-only tool:

1. 30ed1cb27 graduated the filesystem tool bodies, including the synchronous Bash body, into engine/adapter/fstools.
2. 8d187f073 added background:true and BashStatus, requiring an agent-loop-aware Bash implementation and leaving the synchronous fstools version in place.

The retained fstools implementation may have been intentional as an external-embedding reference, but no concrete user is known.

Proposal

Apply the YAGNI principle: determine whether there is a real external consumer that needs fstools.ShellTool without the engine’s agent implementation. If not, remove the synchronous Shell tool body and its internal/adapter/tools re-export, leaving a single canonical agent-loop Shell implementation.

Do not remove it merely as a rename cleanup. First assess the public engine-module/API impact and whether a future environment-scoped managed-execution design should instead make a regular tool body canonical.

Acceptance considerations

• Identify concrete external consumers before preserving a public/reference API solely for hypothetical embedding.
• If removal is approved, update engine API compatibility artifacts and documentation under the engine compatibility policy.
• Preserve the canonical Shell command-policy and background-job behavior.
• Avoid broadening engine/agent dependencies on concrete adapters.
• If retained, document the supported external-embedding use case and why the duplication is worth maintaining.

Relates to #1109.