A failed estate Job stays failed until what names it changes #461

What happened

The Vault policy job and the catalog method's Job are named by a digest of what they run with (#454, #459). On 2026-10-16 the first postgres-catalog-7b66ab65da64 failed, because the Vault policy job had not yet written its role. Once a fixed policy job had run, the catalog Job's inputs were unchanged, so it kept its name and stayed Failed. Flux's health check kept estate-vso-secrets not Ready, which held apps-delivery, apps-tribelt and apps-estate-dashboard, until the Job was deleted by hand. The hourly CronJob runs the same pod and succeeded, but the unit's health check reads the hash-named Job.

What should happen

A Job that failed for a reason outside its own inputs runs again without a person deleting it. Options: the unit does not health-check the one-shot Job and relies on the CronJob, the Job carries a backoffLimit and deadline long enough to outlast the policy job writing its role, or the catalog Job is ordered after the policy job.

Acceptance criteria

• A catalog Job that fails because its Vault role does not exist yet succeeds on its own once the role exists, with no manual delete.
• Both implementations and the oracle trees agree.