Clone missing production repos in system update, run it on -f, standalone cleanup script

[hello-bharadwaj]

Summary

These changes make the -f (fresh Ubuntu / factory install) path end in the same state as the -g (golden image) path, so a robot installed either way can proceed into the production test flow (FAB bench QC and onward) from stretch_production_tools_ii.

factory/24.04/stretch_system_update.sh

• Creates ~/repos if it doesn't exist instead of exiting with an error.
• Clones any of the five production repos (stretch_firmware_ii, stretch_production_tools_ii, stretch_fleet_ii, stretch_production_data_ii, stretch4_pyhesai_wrapper) that aren't already present, then checks out the right branch (develop for firmware, main/master for the rest) and pulls. A failed clone (e.g. missing credentials) skips that repo instead of aborting the whole update.
• Upgrades the four robot pip packages: hello-robot-stretch4-body, -urdf, -flying-gripper, -tray.

stretch_new_robot_install.sh

• The -f factory install now also runs stretch_system_update.sh (after dev tools), so fresh installs get ~/repos populated with the production repos just like -g golden image setups do. Previously a fresh install ended with no ~/repos at all, and the production tools updater would hard-fail on it.

factory/24.04/stretch_cleanup_robot.sh

• Synced with the latest utils/cleanup_production_data.sh from stretch_production_tools_ii (adds Antigravity uninstall, system trash clearing, shell history/~/Videos clearing, and the final pip package refresh).
• Inlined minimal output helpers (section/ok/warn/fail, a simplified run_step with timeout, print_summary) so it runs standalone without production_logger.sh — no log files or progress bar, same steps and behavior otherwise.

Notes for reviewers

• After either -f or -g, the production tools Python package still needs its editable install via ~/repos/stretch_production_tools_ii/utils/stretch_system_update.sh (Production Guide Section C) before FAB_manager.py can run — unchanged by this PR.
• stretch_system_update.sh has no set -e, so pull/pip failures don't fail the script; left as-is for now.