Add env step/reset time profiling with per-functor breakdown

[yuecideng]

Description

This PR adds EnvProfiler, a toggleable, hierarchical wall-time profiler for the gym env reset/step pipeline, with automatic per-functor breakdown for event and observation functors.

What's included:

• New EnvProfilerCfg + EnvProfiler (embodichain/lab/gym/utils/profiler.py). Section names are built from the active call stack (Isaac Lab Timer semantics); a parent's time includes its children. No-op (zero overhead) when cfg.profiler is None.
• BaseEnv.step / reset / get_obs and EmbodiedEnv manager calls are instrumented with profiler sections. The report is flushed in close() before sim.destroy() (which exits the process without returning to Python).
• ManagerBase._call_functor helper; EventManager.apply and ObservationManager.compute route through it so every registered event/obs functor is timed individually and automatically, nesting under the manager call site. Interval functors are timed per-firing (calls reflects interval_step), not per-step.
• The sensor section is split into render_camera_group (actual render) and sensor_fetch (data fetch).
• CLI: --profile / --profile_output on run-env.
• Docs: cli.md Profiling section, env-framework & manager-functor agent-context topics, gym.utils API reference.

Motivation: There was no easy way to see which module in the reset/step chain (or which individual functor) dominates runtime. Now run-env --profile ... prints a breakdown like:

step.update_sim_state.event_interval
  record_camera        calls=196  mean=0.380ms   (interval_step=1)
  random_light         calls=20   mean=0.318ms   (interval_step=10)
reset.initialize_episode.event_reset
  prepare_extra_attr   calls=1    176.008ms

GPU-memory profiling is intentionally out of scope for this PR (time-only).

Dependencies: none

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Enhancement (non-breaking change which improves an existing functionality)
• Breaking change (existing functionality will not work without user modification)
• Documentation update

Screenshots

N/A — sample report shown in Description.

Checklist

• I have run the black . command to format the code base.
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• Dependencies have been updated, if applicable.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.