Remove legacy tool-wrapper fallback after projection helper is required

[chubes4]

Problem

PR #538 migrated selected DMC workspace and GitHub model tools to Data Machine's ability-native projection helper, but intentionally kept legacy wrapper registration as a fallback when the helper is unavailable and left bespoke alias/composed wrappers in place.

That is the right migration shape, but the fallback should be tracked so DMC does not permanently maintain two model-tool registration paths.

Desired outcome

Once DMC requires a Data Machine version that includes datamachine_register_ability_tool(), remove the legacy fallback registration for tools that can be projected directly from abilities. Keep bespoke wrappers only where they add real model-specific behavior.

Acceptance criteria

• Raise or document the minimum Data Machine dependency that guarantees the projection helper exists.
• Remove fallback BaseTool registration for tools fully covered by ability-native projections.
• Keep model-facing tool names stable unless a deliberate migration note is added.
• Document which remaining wrappers are intentionally bespoke and why.
• Regression tests prove projected DMC tools are offered to the model and execute through canonical abilities.

Related

• DMC migration tracker: Replace duplicated model-tool wrappers with ability-native projections #536
• DMC migration PR: Use ability-native projections for DMC tools #538
• Data Machine projection helper: Expose ability tool projection helper data-machine#2475

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (openai/gpt-5.5)
• Used for: Boundary audit follow-up and tracker drafting; Chris remains responsible for prioritization.