docs: use --hostname all in the Bitwarden webhook example (#6850)

* docs: use --hostname all in the Bitwarden webhook example

Bitwarden CLI 2026.6.0 added a Host header allowlist to `bw serve`, on top of
the Origin header check that was already there. With `--hostname 0.0.0.0` the
allowlist is built from the bound hostname, so it only contains localhost,
127.0.0.1, [::1] and 0.0.0.0 at the serve port.

The webhook provider reaches the CLI through a Kubernetes Service, so the Host
header is a service name such as bitwarden-cli.bitwarden.svc:8087. That is not
on the allowlist, so bw serve returns 403 and logs `Blocking request with
disallowed Host "..."`. Every ExternalSecret backed by these stores fails once
the image is built from 2026.6.0 or later.

Switch the documented entrypoint.sh to `--hostname all`, which binds every
interface and skips the Host allowlist while leaving the Origin header check
active. Older releases already accept `all`, so the same entrypoint works on
either side of 2026.6.0.

This is preferable to --disable-origin-protection, which switches off both
guards. The webhook provider does not send an Origin header, so keeping that
check costs nothing here.

Signed-off-by: Gary T. Giesen <ggiesen@giesen.me>

* docs: clarify the Host header comes from the SecretStore url

Address review feedback on the Bitwarden webhook example.

State that the Host header is whatever authority the SecretStore url carries,
rather than implying a fixed value, and keep the FQDN form since a bare
service name resolves against the controller pod's search list and does not
reach a Service in another namespace.

Also note that pinning Host through the store's headers is not a workaround:
those entries go through Header.Add, and Go takes the request Host from the
URL rather than from Header["Host"], so the header is silently ignored.

Signed-off-by: Gary T. Giesen <ggiesen@giesen.me>

---------

Signed-off-by: Gary T. Giesen <ggiesen@giesen.me>
Co-authored-by: Jean-Philippe Evrard <jean-philippe.evrard+rochepub@external.roche.com>

docs/examples/bitwarden.md

@@ -69,9 +69,43 @@ fi
 bw unlock --check
 
 echo 'Running `bw server` on port 8087'
-bw serve --hostname 0.0.0.0 #--disable-origin-protection
+bw serve --hostname all
 ```
 
+!!! warning "Bitwarden CLI 2026.6.0 and later: use `--hostname all`"
+
+    `bw serve` 2026.6.0 added a Host header allowlist on top of its existing
+    Origin header check. With `--hostname 0.0.0.0` the allowlist is built from
+    the bound hostname, so it contains only `localhost:8087`, `127.0.0.1:8087`,
+    `[::1]:8087` and `0.0.0.0:8087`.
+
+    The webhook provider sends whatever authority the SecretStore `url` carries
+    as the `Host` header. For a store pointing at
+    `http://bitwarden-cli.bitwarden.svc:8087` that authority is not on the
+    allowlist, so `bw serve` answers `403` and logs:
+
+    ```
+    Blocking request with disallowed Host "bitwarden-cli.bitwarden.svc:8087"
+    ```
+
+    Every ExternalSecret backed by these stores fails.
+
+    `--hostname all` binds every interface and skips the Host allowlist, which
+    is why the example above uses it. It is also accepted by older releases, so
+    the same entrypoint works either way.
+
+    Prefer this over `--disable-origin-protection`. That flag turns off the
+    Origin header check as well, whereas `--hostname all` leaves it in place.
+    The webhook provider does not send an `Origin` header, so it is unaffected.
+
+    Pinning the Host from the store does not work as a substitute. Entries in
+    the store's `headers` are applied with `Header.Add`, and Go takes the
+    request Host from the URL rather than from `Header["Host"]`, so a
+    `Host: localhost:8087` header is silently ignored.
+
+    Neither option authenticates callers. The NetworkPolicy below is what
+    restricts access to `bw serve`, so deploy it.
+
 ## Deploy Bitwarden credentials
 
 ```yaml