[Breaking change] Going all-in on MCP

[Darktex]

Summary

I have been thinking about revising our abstractions to really go all-in on MCP and reduce the friction between Prod and Training. If accepted, our RFCs (and code)
will change meaningfully.

We are not at this stage yet. This PR introduces a single consolidated RFC (env_tools_rfc.md) that proposes significant architectural changes. It's meant to
spark discussion and alignment before we commit to implementation.

Key Changes Proposed

• Environment = MCP Servers + Simulation Layer: Environment wraps and manages MCP servers directly, with a simulation layer (HTTP) that disappears in production
• Dual protocol architecture: HTTP for simulation control (reset/step), MCP for agent-tool interaction (present in both training and prod)
• Tool registry with sim/prod mapping: Explicit registry maps production tools to simulation equivalents, with HF Hub integration for community-contributed
  mappings
• Git-based checkpointing: Automatic transactional state management with async sidecar for performance
• Event queue as first-class citizen: Empty queue = static env, populated = dynamic env
• Data + evals included in Environment: Clear simulation boundary, everything needed for training lives in Environment abstraction

See rfcs/env_tools_rfc.md for full details, rationale, and design decisions.

Progression Plan

• Phase 1 (Current): Initial proposal as single RFC explaining the delta
• Phase 2: Update existing RFCs (000-004) to reflect new design decisions
• Phase 3: Revise project timelines and release plan to accommodate changes

Discussion Points

1. Tool registry approach and HF Hub integration strategy
2. Whether to host sim tools directly on HF Hub (currently marked as "under discussion")
3. Checkpointing transactionality limitations and annotations
4. Migration path for existing environments

Feedback welcome on all aspects - this is the right time to course-correct before implementation begins.