urlaubsverwaltung: correct the env-collision claim, answer the recovery question

The chart told operators that adding a duplicate env name to an installed
release makes the next upgrade fail in the API server, quoting "The order in
patch list ... doesn't match $setElementOrder list". Measured against helm
3.19.0 and Kubernetes 1.35, it does not fail: the upgrade succeeds, helm prints
"Release has been upgraded", and Kubernetes merges the env list by name, so the
duplicate pair collapses to the chart's own entry and the operator's override is
discarded without a word. At install time the same values behave differently -
both entries reach the pod, the later one wins, and the API server says so with
"hides previous definition of ..., which may be dropped when using apply".

The advice that followed from the old claim survives - such a switch only takes
at install time - but the stated reason was wrong in the dangerous direction. A
reader who expects a loud failure treats a green upgrade as proof the override
took effect, and green is exactly what a silently dropped override looks like.
The text now names the real failure mode and tells the reader to read the value
back off the Deployment. README carries the same correction, because every chart
in this repo offers the same additive env block.

Also records what the earlier measurement left open. With the database scaled
back up the pod returns to Ready on its own after about five seconds, restart
count still 0, so leaving the liveness group untouched costs no manual recovery.
And the limit of that signal belongs next to it: the db indicator validates a
connection, not the schema, so a database that came back empty still put the pod
back to Ready with /actuator/health at 200.

urlaubsverwaltung/values.yaml

@@ -73,11 +73,14 @@ urlaubsverwaltung:
   # setting trades a permanently false alarm for silence, and silence is only
   # correct as long as there is nothing to report about.
   #
-  # That override repeats a name the chart already sets, and env is additive:
-  # it renders the variable twice (the later entry wins in the container), and
-  # adding it to an ALREADY INSTALLED release makes the next upgrade fail in
-  # the API server. See the "env IS ADDITIVE ONLY" section of NOTES.txt — the
-  # switch has to go in at install time, not at upgrade time.
+  # That override repeats a name the chart already sets, and env is additive, so
+  # it renders the variable twice. At INSTALL time both entries reach the pod and
+  # the later one — yours — wins in the container. Added to an ALREADY INSTALLED
+  # release it is lost instead: Kubernetes merges env by name, the pair collapses
+  # to the chart's own entry, and helm still reports a successful upgrade. The
+  # override does not fail loudly, it fails silently. See the "env IS ADDITIVE
+  # ONLY" section of NOTES.txt — the switch has to go in at install time, and
+  # after any such change the result belongs verified on the live Deployment.
   livenessProbe:
     httpGet:
       port: 8080