fix: remove mlm workspace

.gitmodules

@@ -1,8 +1,3 @@
-[submodule "3rdparty/Megatron-LM"]
-	path = 3rdparty/Megatron-LM-workspace/Megatron-LM
-	url = https://github.com/NVIDIA/Megatron-LM.git
-	branch = main
-	shallow = true
 [submodule "3rdparty/Megatron-Bridge"]
 	path = 3rdparty/Megatron-Bridge-workspace/Megatron-Bridge
 	url = https://github.com/NVIDIA-NeMo/Megatron-Bridge.git

docs/design-docs/dependency-management.md

@@ -24,7 +24,7 @@ A **development workflow** is when you actively modify dependencies, submodules,
 
 - **Version mismatch**: Using a container built from commit A, but your local NeMo RL code is at commit B, where B has different submodule versions or Python dependencies than A
 - **Dependency changes**: Actively developing new features that require updated Python packages
-- **Submodule modifications**: Working with modified versions of Megatron-LM, NeMo-Automodel, or other submodules
+- **Submodule modifications**: Working with modified versions of Megatron-Bridge, NeMo-Automodel, or other submodules
 
 > [!WARNING]
 > If your container was built from commit `abc123` which used `vllm==0.9.0`, but your local checkout is at commit `def456` which requires `vllm==0.10.0`, you are in a development workflow. The container's cached environments won't match your code's requirements.
@@ -161,7 +161,7 @@ The rebuilt container will have all virtual environments pre-cached with your up
 
 ### Option 3: Classic Workflow - Mounting Modified Submodules
 
-For situations where you're **only changing submodules** (like nemo-automodel, NeMo Gym, Megatron-LM, or Megatron-Bridge) but **not changing Python package versions**, you can use a classic mounting approach. This workflow assumes that the non-submodule Python packages in your local checkout match what the container was built with.
+For situations where you're **only changing submodules** (like nemo-automodel, NeMo Gym, or Megatron-Bridge, or Megatron-LM which is a submodule in Megatron-Bridge) but **not changing Python package versions**, you can use a classic mounting approach. This workflow assumes that the non-submodule Python packages in your local checkout match what the container was built with.
 
 The container's NeMo RL code is located at `/opt/nemo-rl`. By mounting your local `3rdparty/` directory over the container's `/opt/nemo-rl/3rdparty/`, you can swap out submodules without rebuilding environments or containers.
 
@@ -193,7 +193,7 @@ This mounts:
 > [!IMPORTANT]
 > This workflow is **only suitable when**:
 > - Python package versions in `pyproject.toml` and `uv.lock` haven't changed
-> - You're only modifying code within submodules (nemo-automodel, NeMo Gym, Megatron-LM, Megatron-Bridge)
+> - You're only modifying code within submodules (nemo-automodel, NeMo Gym, Megatron-LM within Megatron-Bridge, Megatron-Bridge)
 > - The submodule commits/branches are compatible with the installed package versions
 
 If you've changed Python package versions or dependencies outside of submodules, use Option 1 (`NRL_FORCE_REBUILD_VENVS=true`) or Option 2 (rebuild the container) instead.

pyproject.toml

@@ -167,7 +167,7 @@ test = [
 ]
 
 [tool.uv.sources]
-megatron-core = { workspace = true }
+megatron-core = { path = "3rdparty/Megatron-Bridge-workspace/Megatron-Bridge/3rdparty/Megatron-LM", editable = true }
 nemo-automodel = { workspace = true }
 megatron-bridge = { workspace = true }
 nemo_gym = { workspace = true }
@@ -192,7 +192,6 @@ sgl-kernel = { git = "https://github.com/sgl-project/sglang", rev = "3167bcc01c3
 
 [tool.uv.workspace]
 members = [
-  "3rdparty/Megatron-LM-workspace",
   "3rdparty/Automodel-workspace/Automodel",
   "3rdparty/Megatron-Bridge-workspace",
   "3rdparty/Gym-workspace/Gym",
@@ -253,6 +252,7 @@ override-dependencies = [
   "llguidance>=1.3.0,<1.4.0",
   # Override setuptools range in other dependencies to address CVE GHSA-58pv-8j8x-9vj2
   "setuptools>=80.10.2",
+  "nvidia-cutlass-dsl>=4.3.1",
 ]
 # CVE fixes
 constraint-dependencies = [