PR #26 added the git-clone initContainer but still trusted the GIT_REPO_URL
secret verbatim. That secret historically contains gitea.rogi.casa, which
526s through Cloudflare, so the clone still fails with 'Not a git repository'.
Normalize the host to git.rogi.casa at runtime (sed) so the clone works
regardless of the secret's stale host. Directly addresses the subdomain bug.
The git-sync CronJob only ran `git pull`/`git push` against /data/myorg
but never ensured the repo existed. The clone was solely the Deployment's
git-clone initContainer's job, and when that didn't populate the volume the
cron pod failed with 'Not a git repository: /data/myorg' on every run (and
swallowed the error, exiting 0).
Add an idempotent git-clone initContainer (guarded by [ ! -d /data/myorg/.git ])
so the cron job self-heals and actually syncs.
Refs: myorg-git-sync-* 'Pull: Error: Not a git repository' (last 24h+)
CronJob pods were stuck in ImagePullBackOff because they referenced
the local-only image 'myorg-assistant:latest' which is not present
on the node. Switch all 5 cronjobs to the Gitea registry image
git.rogi.casa/roger/myorg-assistant/myorg-assistant:fcf79bf
(matching the Deployment), set imagePullPolicy: Always, and add
imagePullSecrets: gitea-registry so they can authenticate to the
private registry.
