refactor: audit all sub-repo prestart.sh scripts and extract non-environment-setup logic

[mairas]

Background

prestart.sh scripts in sub-repos (e.g., halos-core-containers) were originally scoped to one job: set up the runtime environment for the container before it starts. Over time they have accumulated logic that doesn't belong there — certificate lifecycle management, config file installation, OIDC client registration, dynamic routing configuration, and similar housekeeping that runs unconditionally on every service start.

This creates two problems:

1. Upgrade propagation bugs. Logic gated behind if [ ! -f ] guards (example: dynamic config installation in halos-core-containers/prestart.sh:164) silently skips work on already-provisioned systems. The guard was intended as a first-boot check but has the side effect of freezing installed files across upgrades.

2. Entanglement. Mixing one-time provisioning, periodic rotation, and pure startup-env work in a single script makes each concern harder to reason about, test, and change independently.

Goal

Go through every prestart.sh (and equivalent) in the workspace sub-repos and identify actions that are not strictly "prepare the environment for this container to start right now." Candidates for extraction:

• Certificate lifecycle — CA selection, leaf signing, rotation, sentinel logic (currently in halos-manage-certs, which is already partially extracted; verify nothing leaked back into prestart)
• Dynamic config installation — copying package-shipped files to the live config directory; should be idempotent and always-overwrite (the if [ ! -f ] guard in halos-core-containers/prestart.sh was patched in fix(routing): strip HSTS at per-app entrypoints halos-core-containers#161, but the pattern may recur elsewhere)
• One-time provisioning — database seeds, first-boot user setup, OIDC client registration — that run unconditionally even when the system is already provisioned
• Periodic housekeeping — anything that could run as a systemd timer or cron job instead of blocking container startup

For each identified action, determine the right home:

• Separate systemd service (runs once, has a clear dependency graph)
• Systemd timer / cron job (periodic)
• Postinst script in the Debian package (true one-time, at install time)
• Inline in prestart.sh only if it genuinely must run on every container start

Scope

Sub-repos with known prestart.sh or equivalent startup scripts:

• halos-core-containers
• halos-marine-containers
• Any others discovered during the audit

Acceptance criteria

• All prestart.sh scripts audited; findings documented
• Each non-env-setup action has a concrete extraction proposal (or a documented reason to stay)
• At least the highest-risk cases (those with if [ ! -f ] guards or unconditional write operations) are extracted or fixed
• No regression in service startup behavior