Harden Kubernetes workload security contexts consistently

## Summary

Harden all Kubernetes manifests under `k8s/` in one consistent security pass.

The new migration Jobs currently use Kubernetes default security settings. This is consistent with the existing manifests, but it leaves workloads with unnecessary default privileges. Apply the same security baseline across the manifest set instead of hardening only the migration Jobs.

## Required changes

For each applicable workload manifest under `k8s/`, including production and staging variants:

- Set `automountServiceAccountToken: false` when the workload does not require Kubernetes API access.
- Add pod-level `securityContext` settings for non-root execution and `seccompProfile.type: RuntimeDefault`.
- Add container-level `securityContext` settings that disable privilege escalation, drop all Linux capabilities, and use a read-only root filesystem where the workload supports it.
- Define explicit non-root UID and GID settings where they are compatible with the container image.
- Add writable temporary volumes or mounts only where a read-only root filesystem requires them.
- Preserve required runtime behaviour for backend, worker, text-service, migration, and related workloads.

## Affected areas

- `k8s/migrate-job.yaml`
- `k8s/staging/migrate-job.yaml`
- Other workload manifests under `k8s/` and `k8s/staging/`

## Acceptance criteria

- Production and staging manifests use the same documented security baseline where applicable.
- The migration Jobs have hardened pod and container security contexts.
- Workloads run successfully with the hardened settings.
- Any required exception is documented with its reason.
- Kubernetes manifest security scans no longer report the applicable default-security-context findings.

## Backlinks

- Pull request: https://github.com/DDMAL/mothra/pull/256
- Review comment: https://github.com/DDMAL/mothra/pull/256#discussion_r3815746445

Requested by: @kyrieb-ekat