Fix(UI): Preserve Chaos Checker Container resources in TuneExperiment

[Debjyoti2004]

Fix(UI): Preserve Chaos Checker Container resources in TuneExperiment (Resolves Issue #5231)

This Pull Request resolves Issue #5231 by implementing logic to ensure that user-defined CPU and memory resource requests and limits for the Chaos Checker container are preserved when an experiment is modified through the Visual Builder (Tune Experiment Form).

Types of changes

What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

[ ] New feature (non-breaking change which adds functionality)
[x] Bugfix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices applies)

Detailed Explanation & Resolution

Root Cause of the Bug

The core problem was that the frontend form submission logic (onSubmit handler in FaultTunablesTab.tsx) used a "whitelisting" approach. This logic generated a new ChaosExperiment manifest based only on the fields that were explicitly visible and edited (like environment variables). Any complex, non-edited structures, such as the resources object for the runner component, were entirely omitted from the new payload, effectively resetting the resource limits in the final YAML.

Technical Solution

The patch modifies the onSubmit handler in FaultTunablesTab.tsx to ensure the preservation of the data structure. It performs a manual, structured deep merge for the non-form fields:

1. It safely initializes the nested object path (engineCR.spec.components.runner) in the new configuration (updatedFaultData) using TypeScript casting (as any).
2. It then explicitly copies the complete resources object from the old, complete manifest into the new manifest before the state is updated.

This guarantees that the user's resource settings persist correctly during the round-trip (YAML → Visual Editor → YAML).

Verification

The fix was validated locally by performing the "Round-Trip Test": adding custom resources in YAML, editing a different field in the Visual Builder, and confirming the custom resources block was retained in the resulting YAML.

Checklist

Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[x] I have signed the commit for DCO to be passed.
[x] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[ ] I have added necessary documentation (if appropriate)