test(dev-deploy): try Caddy flush_interval -1 on EdgeGateway path

Hypothesis test for the intermittent
"Fetch API cannot load … SubscribeEvents due to access control
checks" error visible to Safari users on https://www.galaxy.lan.

Server-side CORS headers are present and correct (verified live);
the browser reports 0 bytes received and the gateway sees the
stream context canceled after ~2 s. galaxy-caddy's reverse_proxy
log shows the same window: `error: reading: context canceled` with
sub-millisecond upstream duration on every retry. The EventStream
client treats the transport-level abort as a transient error and
reconnects with backoff, producing the tight open/close pattern
observed in `push_fanout.go` logs.

`flush_interval -1` disables Caddy's default response buffering
on the streaming path so the gateway's initial
`gateway.service_time` event reaches the browser without waiting
for a buffer flush. If Safari was canceling the stream because
no bytes landed within its fetch-streaming idle window, this
should stop the reconnect loop. To be verified on dev-deploy via
workflow_dispatch on this branch, no merge to `development` yet.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

tools/dev-deploy/Caddyfile.dev

@@ -27,7 +27,19 @@
         @connect path /galaxy.gateway.v1.EdgeGateway/*
         handle @connect {
             # `flush_interval -1` disables Caddy's response buffering on
-        }
+            # this path so server-streaming Connect-Web responses (the
+            # SubscribeEvents push channel) deliver each event to the
+            # browser as soon as the gateway flushes it. Without it
+            # Caddy buffers the initial `gateway.service_time` frame
+            # and Safari's fetch-streaming layer treats the body as
+            # idle, cancels within ~2 s, and falls into a tight
+            # reconnect loop the user sees as the intermittent
+            # "Fetch API cannot load … due to access control checks"
+            # console error.
+            reverse_proxy galaxy-api:9090 {
+                flush_interval -1
+            }
+        }
         reverse_proxy galaxy-api:8080
     }
 }