Skips apply_external_force_torque when both ranges are zero (#5688)

# Description

Fast-path early-return in
:func:`~isaaclab.envs.mdp.events.apply_external_force_torque` when both
`force_range` and `torque_range` are exactly zero — a common
configuration for tasks that declare the event term but apply no
disturbance.

Before this change, zero-wrench configurations were still sampled,
written into the dual-buffer `WrenchComposer` introduced in #5265, and
pushed through the per-step compose-and-apply path in
`Articulation.write_data_to_sim`, paying the full per-step cost for what
is semantically a no-op. Applying a zero wrench is equivalent to not
applying one at all, so the function now returns immediately when both
ranges are zero.

This restores the H1, G1, and Anymal-C `Velocity-Rough` throughput
observed prior to #5265, as recorded in the OmniPerf DB regression
flagged in `isaac-sim/IsaacLab-Internal#906`.

**Scope limitation.** This only addresses the zero-force case. Tasks
that apply non-zero external forces (curriculum disturbances, push
events, domain-randomized wrenches) still pay the per-step body-frame
recompose cost under the new dual-buffer architecture. That broader
optimization (compose caching / kernel fusion) is tracked separately in
`isaac-sim/IsaacLab-Internal#911` and is out of scope here.

**Correctness.** The dual-buffer `WrenchComposer` architecture from
#5265 is untouched; this fix sits one layer above it in the event term.
For any non-zero `force_range` or `torque_range`, the early-return
predicate is false and behavior is unchanged.

Fixes `isaac-sim/IsaacLab-Internal#906`
Follow-up: `isaac-sim/IsaacLab-Internal#911`

## Type of change

- Bug fix (non-breaking change which fixes an issue)

## Screenshots

N/A — performance fix, no user-visible behavior change.

## Checklist

- [x] I have read and understood the [contribution
guidelines](https://isaac-sim.github.io/IsaacLab/main/source/refs/contributing.html)
- [x] I have run the [`pre-commit` checks](https://pre-commit.com/) with
`./isaaclab.sh --format`
- [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] I have added a changelog fragment under
`source/<pkg>/changelog.d/` for every touched package (do **not** edit
`CHANGELOG.rst` or bump `extension.toml` — CI handles that)
- [x] I have added my name to the `CONTRIBUTORS.md` or my name already
exists there

---------

Co-authored-by: Kelly Guo <kellyg@nvidia.com>

Author: AntoineRichard

source/isaaclab/changelog.d/fix-zero-wrench-fast-path.rst

@@ -0,0 +1,12 @@
+Fixed
+^^^^^
+
+* Fixed a per-step performance regression in :func:`~isaaclab.envs.mdp.events.apply_external_force_torque`
+  when the event was configured with all-zero ``force_range`` and ``torque_range`` (a common default
+  for tasks that declare the event term but apply no disturbance). The event was unconditionally
+  sampling zero wrenches and routing them through the dual-buffer ``WrenchComposer`` introduced in
+  PR #5265, paying the full per-step compose-and-apply cost in
+  :meth:`~isaaclab.assets.Articulation.write_data_to_sim` for what is semantically a no-op. The
+  function now returns early when both ranges are exactly zero. This restores the H1, G1, and
+  Anymal-C ``Velocity-Rough`` throughput observed prior to PR #5265. Behaviour for non-zero ranges
+  is unchanged.

source/isaaclab/isaaclab/envs/mdp/events.py

@@ -1709,6 +1709,10 @@ def apply_external_force_torque(
     # resolve number of bodies
     num_bodies = len(asset_cfg.body_ids) if isinstance(asset_cfg.body_ids, list) else asset.num_bodies
 
+    # Skip force application if the wrench ranges are zero
+    if force_range[0] == 0.0 and force_range[1] == 0.0 and torque_range[0] == 0.0 and torque_range[1] == 0.0:
+        return
+
     # sample random forces and torques
     size = (len(env_ids), num_bodies, 3)
     forces = math_utils.sample_uniform(*force_range, size, asset.device)