fix(readiness): bump Odoo readinessProbe failureThreshold 2 -> 15

Heavy addon installs (e.g. ks_dashboard_ninja) blocked /web/login
probes for >10s, causing K8s to pull the Pod from Endpoints; Traefik
then 503d the operator addon-apply RPC. failureThreshold: 15 (~75s
of headroom) covers the install window without affecting true
pod-restart detection (initialDelay gates boot).

Chart 0.1.0 -> 0.1.1.

Chart.yaml

@@ -5,7 +5,7 @@ description: |
   Variation between instances is expressed via values.yaml only.
   No chart variants. No string-templating in Tower.
 type: application
-version: 0.1.0
+version: 0.1.1
 appVersion: "1.0"
 keywords:
   - odoo

templates/odoo-deployment.yaml

@@ -289,10 +289,14 @@ spec:
           # 16/17/18/19 — /web/health is 17+. Use login HTTP 200 as
           # readiness signal.
           #
-          # 5s period so K8s catches an Odoo restart (addon install
+          # 5s period catches a true pod restart fast (initialDelay
-          # via the Apps menu can trigger one) within a single probe
+          # gates the boot path; failureThreshold only matters once
-          # cycle and pulls the Pod from Endpoints — paired with the
+          # the pod has been ready). failureThreshold: 15 (= 75s of
-          # Traefik retry middleware that swallows the brief gap.
+          # consecutive probe failures) gives Odoo headroom to install
+          # heavy modules (e.g. ks_dashboard_ninja) without K8s pulling
+          # the Pod from Endpoints mid-install — which produced 503s
+          # at the operator surface during addon-apply. Paired with
+          # the Traefik retry middleware for short gaps.
           readinessProbe:
             httpGet:
               path: /web/login
@@ -300,7 +304,7 @@ spec:
             initialDelaySeconds: 30
             periodSeconds: 5
             timeoutSeconds: 5
-            failureThreshold: 2
+            failureThreshold: 15
           livenessProbe:
             tcpSocket:
               port: 8069