Add Kubernetes probe configuration guidance to deployment docs (#3803)

## Summary

Added Kubernetes health probe configuration guidance to the deployment
documentation, explaining why readiness probes need special handling
when Electric returns HTTP 202 during startup.

**User impact:** Kubernetes operators can now properly configure probes
to avoid routing traffic to Electric pods that are still initializing.

## Approach

The core issue: Kubernetes `httpGet` probes treat *any* 2xx response as
success. Electric's health endpoint returns:
- `200 OK` with `{"status":"active"}` when fully ready
- `202 Accepted` with `{"status":"waiting"}` during startup

This means a naive `httpGet` readiness probe marks pods as ready while
Electric is still initializing—potentially routing traffic to pods that
will return errors.

**Solution:** Different probe types for different purposes:
- **Liveness:** Use standard `httpGet` (any response = alive)
- **Readiness:** Use `exec` with curl to check for exactly HTTP 200

```yaml
readinessProbe:
  exec:
    command:
      - sh
      - -c
      - |
        test "$(curl -so /dev/null -w '%{http_code}' http://localhost:3000/v1/health)" = "200"
```

## Key Invariants

1. Readiness probe must only succeed when Electric returns exactly HTTP
200
2. Liveness probe should succeed on any response (including 202)
3. Electric container must include `curl` (it does)

## Non-goals

- Not adding custom health check endpoints to Electric itself
- Not changing Electric's health response behavior (202 during startup
is correct)

## Trade-offs

**Alternative considered:** Could document using `tcpSocket` probes
instead. Rejected because:
- TCP connection success doesn't indicate application readiness
- HTTP-level check provides more meaningful health signal

**Alternative considered:** Suggest users build custom sidecar
containers for health checking. Rejected as overly complex when a simple
exec probe suffices.

## Verification

```bash
# View the documentation changes
pnpm --filter @electric-sql/docs dev
# Navigate to /docs/guides/deployment and check the Kubernetes probes section
```

## Files Changed

| File | Change |
|------|--------|
| `website/docs/guides/deployment.md` | Added "Kubernetes probes"
subsection with liveness/readiness probe YAML examples and explanation |

Co-authored-by: Claude <noreply@anthropic.com>

Author: KyleAMathews

website/docs/guides/deployment.md

@@ -183,6 +183,40 @@ curl http://localhost:3000/v1/health
 # {"status":"active"}
 ```
 
+#### Kubernetes probes
+
+When deploying Electric on Kubernetes, note that standard `httpGet` probes consider any 2xx response as success. This means an `httpGet` readiness probe would incorrectly mark the pod as ready when Electric returns `202` (still starting up).
+
+For **liveness probes**, `httpGet` works fine since any response indicates the service is alive:
+
+```yaml
+livenessProbe:
+  httpGet:
+    path: /v1/health
+    port: 3000
+  initialDelaySeconds: 10
+  periodSeconds: 10
+  timeoutSeconds: 2
+```
+
+For **readiness probes**, use an `exec` probe to check for exactly HTTP 200. The Electric container includes `curl`:
+
+```yaml
+readinessProbe:
+  exec:
+    command:
+      - sh
+      - -c
+      - |
+        test "$(curl -so /dev/null -w '%{http_code}' http://localhost:3000/v1/health)" = "200"
+  initialDelaySeconds: 5
+  periodSeconds: 10
+  timeoutSeconds: 2
+  failureThreshold: 3
+```
+
+This ensures the pod is only marked ready when Electric is fully operational and ready to serve shape requests.
+
 ### Observability
 
 Electric supports [OpenTelemetry](https://opentelemetry.io/) for exporting traces, with built-in support for [Honeycomb.io](https://www.honeycomb.io/). Metrics are also available in StatsD and Prometheus formats.