zipline: strict values.schema.json, ingress gate and null-safe hardening

Three changes, all about values that do not do what they promise:

1. values.schema.json (#68): additionalProperties: false on every
   chart-owned object level, so a key the chart does not read is rejected
   at render time instead of being silently ignored.

2. Ingress gate (#93): the Ingress template is wrapped in
   {{- if .Values.ingress.enabled }} and the key is added to values.yaml
   with default true, so behaviour is unchanged.

   As in rallly, ingress.domain is not a pure Ingress value: the
   StatefulSet also feeds it to CORE_DEFAULT_DOMAIN, the app's default
   domain for generated share links, and did so without required(). The
   guarantee only came from the ungated Ingress template, so the gate
   would have handed out unusable links silently. That read is now
   required() as well; only clusterIssuer becomes unnecessary.

3. Null-safety for hardening, probes and resources (#99): an erased block
   fell back to "securityContext: null" (unhardened), a vanished probe or
   a container without resource accounting. The rebuilt liveness probe
   keeps "/" rather than /api/healthcheck, so a database outage still does
   not restart the pod.

config stays deliberately not null-safe: storage and storageClass are
required(), which puts an erased block in the loud class #99 excludes.

Apart from an added comment, the rendered manifest is unchanged.

zipline/Chart.yaml

@@ -16,7 +16,7 @@ type: application
 # This is the chart version. This version number should be incremented each time you make changes
 # to the chart and its templates, including the app version.
 # Versions are expected to follow Semantic Versioning (https://semver.org/)
-version: 5.0.0+up4.7.0
+version: 6.0.0+up4.7.0
 
 # This is the version number of the application being deployed. This version number should be
 # incremented each time you make changes to the application. Versions are not expected to