v0.12.0 — install Job picks latest snapshot by manifest.created

Install Job now picks the latest snapshot at deploy time

Replaces the fail on >1 manifest.json guard (introduced in #34) with logic that reads each web/imports/*/manifest.json, picks the one with the highest created (UTC ISO 8601), and applies that. Older snapshot dirs are logged as skipped — older but kept in the image as history.

Why

The pre-#34 behaviour was an alphabetical iterate + last-write-win loop, which silently applied stale snapshots alongside the canonical current one ("wrong-design-state renders"). #34 papered over that with a hard fail. Picking latest-by-created is deterministic in a way the alphabetical loop wasn't, so designers can accumulate timestamped snapshot dirs in web/imports/ instead of git rm-ing the previous slug on each release. Git log + commit messages carry the history; the chart picks the right one at deploy time.

What changed

• Snapshot block in templates/job-install.yaml rewritten:
  • 0 manifests → "no snapshots committed yet" (unchanged behaviour)
  • 1 manifest → applied directly (unchanged behaviour, no per-manifest parse)
  • 2+ manifests → PHP one-liner walks each manifest.json, picks highest created, applies that one. Logs every dir as (picked) or (skipped — older) for traceability.
• Hard-fails when all candidate manifests are missing created, listing the candidate dirs.

Breaking

Tenants on charts <0.12.0 with new fp versions producing multiple timestamped snapshots will hit the old "fail on >1" guard. Bump charts before bumping fp.

Cross-repo

Pairs with fp v0.5.0+ (timestamp slug default + fp apply no-arg pick-latest). See workspace .aidocs/timestamp-snapshot-slugs.md for the full plan.

Upgrading

GitOps Chart.yaml or helm upgrade:

-version: 0.11.0
+version: 0.12.0

No values changes. Single-snapshot tenants see no behaviour change; multi-snapshot tenants see the picked + skipped log lines.

Full diff

#35