fix(server): set HOME in podSecuritycontext for migration job

[mathijscarlu]

Summary

Closes #605

This change adds the following to the separate migrations job:

• HOME env variable
• podSecurityContext, as specified in the backgroundServices section

Requirements

• Contributing guide has been read
• Title follows the conventional commits format
• Body includes Closes <issue>, if available
• Added/modified configuration includes a descriptive comment for documentation generation
• Unit tests are added/updated
• Deprecation/removal checks are added in templates/NOTES.txt
• Relevant labels are added
• Draft status is used until ready for review

[mitchnielsen]

Thanks for the contribution @mathijscarlu!

The HOME env var addition looks good. I believe the podSecurityContext implementation has a couple of issues that need fixing:

1. {{- include . | nindent 4 }} won't work because include expects a template name string, not a dict. The pattern used elsewhere in this chart is:

   {{- with .Values.backgroundServices.podSecurityContext }}
   securityContext: {{- . | toYaml | nindent 8 }}
   {{- end }}

2. The second test case (Should set correct pod security context) is indented one level too deep, making it part of the previous test's asserts list rather than a separate test. It also needs a set: block to provide the values and to enable backgroundServices.runAsSeparateDeployment. You can see the test failure here and you should be able to run it locally to confirm it works before pushing up the commit.

Would you also consider adding migrations.podSecurityContext as its own values key (similar to how the migration job already has its own securityContext, affinity, tolerations, etc.) rather than pulling from backgroundServices? This would be more consistent with the existing pattern where the migration job has independent configuration.

[mitchnielsen]

Left a comment requesting small changes 👍🏼