sure: new chart for the we-promise Sure app (1.0.0+up0.7.4)

One StatefulSet with two containers - the Puma web process and a Sidekiq
worker - sharing one ReadWriteOnce PVC at /rails/storage. That shared
volume is the reason they live in one pod: splitting them would need an
RWX volume. Only the web container migrates, because the image entrypoint
runs db:prepare solely for the './bin/rails server' command; the worker is
started through args: so the entrypoint (and its jemalloc preload) stays
in place and the two can never race.

Probes are chosen for what they prove: liveness and startup use Rails'
/up, which is a boot check and touches no database, while readiness uses
'/', which runs User.count through authenticate_user! in self-hosted mode
and therefore fails while Postgres is unreachable. The worker speaks no
HTTP, so all three of its probes ask sidekiqmon whether this pod still
holds a Sidekiq heartbeat in Redis.

Three OnePasswordItem CRs (app, database, redis), ingress.domain kept
required outside the Ingress because APP_DOMAIN and the WebAuthn relying
party read it, strict values.schema.json, CI fixtures with throwaway
Postgres 16 and Redis, and a Renovate manager on semver so the
-alpha/-rc/-hotfix channel and the moving tags are never selected.

renovate.json5

@@ -41,7 +41,7 @@
   prHourlyLimit: 0,
 
   // Minor and patch arrive as separate PRs rather than one combined branch.
-  // With 23 charts a shared branch means one red install-test blocks unrelated
+  // With 24 charts a shared branch means one red install-test blocks unrelated
   // updates, and the separation is what lets a patch be reviewed in seconds.
   separateMinorPatch: true,
 
@@ -485,6 +485,33 @@
       datasourceTemplate: "docker",
       depTypeTemplate: "app-version",
     },
+    {
+      description: [
+        "sure: the registry carries four kinds of tag side by side - releases (0.7.4), the",
+        "prereleases -alpha.N / -rc.N / -hotfix.N, the moving names stable/latest/nightly,",
+        "and one sha-<commit> per build. semver versioning is the whole filter: it parses",
+        "the release line, marks every prerelease isStable === false so `ignoreUnstable`",
+        "never offers one, and rejects the moving names and the sha- tags as unparseable",
+        "rather than ever selecting one. That matters more here than the tag list suggests,",
+        "because automerge is global in this config (top of the file) and majors carry no",
+        "age gate: an update this manager offers is one that merges as soon as the required",
+        "check and the required review are there, so the filtering has to happen at the",
+        "lookup, not at the merge. It is also the reason NOT to write a capture-group regex",
+        "here - the moving tags have to stay outside whatever pattern is used, and 'outside'",
+        "is free with semver.",
+        "",
+        "Upstream calls 'latest' the alpha channel and 'stable' the latest release; at the",
+        "time of writing 'stable' resolves to the same digest as 0.7.4, so pinning the",
+        "version tag loses nothing and keeps the chart's appVersion honest.",
+      ],
+      customType: "regex",
+      managerFilePatterns: ["sure/Chart.yaml"],
+      matchStrings: ["(?m)^appVersion:\\s*\"?(?<currentValue>[^\"\\s]+)\"?"],
+      depNameTemplate: "ghcr.io/we-promise/sure",
+      datasourceTemplate: "docker",
+      depTypeTemplate: "app-version",
+      versioningTemplate: "semver",
+    },
     {
       description: "teamspeak-server: the 6.0.0 line only ships beta tags (6.0.0-beta12.1). Loose versioning compares the numeric parts left to right, so beta12.1 sorts above beta9; semver would rank every beta as an equal prerelease.",
       customType: "regex",