fix: Enforce ReadOnly mode at VolumeMount level instead of Volume level

[The-Flash-Routine]

• Moves readOnly flag from Volume to VolumeMount in Script struct to ensure proper per-mount access control
• Maintains backward compatibility while fixing PVC write access
• ConfigMap mounts remain forced read-only (security best practice)

Why:

• Volume-level readOnly affected all mounts globally (undesirable for multi-container pods)
• VolumeMount-level is the standard Kubernetes pattern for granular control

Testing:

• Tested by setting up a minikube cluster on local and creating a new operator image & using TestRun with a sample script
• Attaching a 5 minute video showing existing functionality + building & deploying new operator image + updated functionality
• Google Drive Video Link: https://photos.app.goo.gl/qF2KiBHnUH51Z4cW7

[CLAassistant]

All committers have signed the CLA.

[The-Flash-Routine]

Hi @yorugac can you please enable workflows to run on my PR

[yorugac]

Hi @The-Flash-Routine, thanks for the PR but there is no issue for this one. Could you please clarify the use case you're trying to fix or improve?
By the PR, it seems like you wish to change the behaviour of .spec.script.volumeClaim.readOnly: this might be a breaking change for some. Some elaboration on the use case would be nice 🙂

[The-Flash-Routine]

Hi @yorugac
Thanks for having a look at my PR.
Yes, no issue exists for this one.
Whilst I was working with k6-operator, I identified this improvement.

Context:
I have a use case of initContainer as part of TestRun resource, which is needed as part of Runner job.

UseCase:
The current method puts the "readOnly=false" flag at "volume" level.
When I mount the same Volume/PVC to initContainer as part of TestRun resource, the initContainer also can write in the PVC.
I want:

1. the Runner's main container can write to Volume/PVC
2. The initContainer should not be able to write

This PR change:
Introduces more granular controls to set "readOnly=false" at Container/VolumeMount level, instead of Volume/PVC level.

Regarding the discussion about breaking-change:
I doubt it would be breaking change for people, as the change will affect new Jobs which are created when TestRun object is created on Kubernetes cluster.
So any existing running jobs (if they are still running while the k6-operator is being updated) will not get affected.
Also the jobs are marked as completed at the end of test.

[The-Flash-Routine]

Also @yorugac there is this short 5 minute demo video attached within this PR
https://photos.app.goo.gl/qF2KiBHnUH51Z4cW7

This would help to see the change live working on my local

[The-Flash-Routine]

@yorugac I see that one of the workflow stages failed due to some intermittent Github connectivity issue.
Can you please trigger those again