fix(extensions): bind community extension ports via ${BIND_ADDRESS}

[yasinBursali]

What

Replace hardcoded 127.0.0.1: port bindings in 29 community extension compose files with ${BIND_ADDRESS:-127.0.0.1}:, matching the pattern established for core services. Wire a new regression test into make test.

Why

Community extensions in resources/dev/extensions-library/services/ hardcoded 127.0.0.1: on every ports: entry. When users opted into LAN exposure via --lan, the dashboard network-mode toggle, or BIND_ADDRESS=0.0.0.0 in .env, only core services responded to the setting. All 29 community extensions remained loopback-only, silently ignoring user intent.

How

• Rewrote 35 port-binding lines across 29 compose files:
  "127.0.0.1:${EXT_PORT:-NNNN}:NNNN" → "${BIND_ADDRESS:-127.0.0.1}:${EXT_PORT:-NNNN}:NNNN"
• Healthcheck test: URLs (container-internal loopback) intentionally preserved — they are not host-exposed bindings.
• Added dream-server/tests/test-bind-address-sweep.sh: greps all community extension compose files for bare 127.0.0.1: port-line entries (bidirectional-verified: passes clean, fails clearly on revert).
• Wired the new test into dream-server/Makefile test: target; inherited by gate: via gate: lint test bats smoke simulate.

Testing

• Automated: YAML parse validated; docker compose -f <sample> config verified port-string substitution is correct; regression test (test-bind-address-sweep.sh) passes clean and fails with a clear message when a file is reverted; make -n test confirms the new test is invoked by the target.
• Manual: Set BIND_ADDRESS=0.0.0.0 in .env, run docker compose config | grep "published" for a community extension (e.g. ollama) — confirm binding shows 0.0.0.0 not 127.0.0.1. With BIND_ADDRESS unset, confirm binding defaults back to 127.0.0.1.

Platform Impact

• macOS: not affected (community extensions run on Docker runtime; port-string substitution is identical across platforms)
• Linux: not affected (same Docker runtime behaviour)
• Windows (WSL2): not affected (same)

Known Considerations

Three services exposed on sensitive ports are worth user awareness when opting into LAN mode — default-loopback is preserved; these are user opt-in only:

• privacy-shield (PII proxy) — LAN exposure makes the scrubbing proxy reachable by other machines on the network.
• gitea SSH port 2222 — SSH exposed to LAN on opt-in.
• frigate RTSP (8554) and WebRTC (8555) — camera stream ports exposed to LAN on opt-in.

No change to default behaviour; all three remain loopback-only unless the user explicitly sets BIND_ADDRESS=0.0.0.0.

[Lightheartdevs]

Audit follow-up after today's merge wave: the original ordering blocker for this PR is now resolved, because #1044 has landed and the compose scanner accepts ${BIND_ADDRESS:-127.0.0.1} syntax.

Current status: GitHub now reports this PR as conflicting (DIRTY/CONFLICTING). Please rebase on current main before it can be reconsidered. After rebase, rerun the bind-address sweep/scanner coverage, because the main risk is still keeping the dashboard install scanner and the community compose fragments in sync.

[yasinBursali]

Rebased on current main (#1044 has landed, scanner now accepts the \${BIND_ADDRESS:-127.0.0.1} syntax). Two conflicts resolved:

• milvus/compose.yaml: union — kept fix(extensions): piper-audio healthcheck timeout gap; publish milvus health port #1034's new 9091:9091 health port + applied \${BIND_ADDRESS} to the 19530 port.
• privacy-shield/compose.yaml: accepted chore(extensions-library): remove community privacy-shield (dead code) #1036's deletion (privacy-shield was removed as dead community code). PR is now 30 files instead of 31.

tests/test-bind-address-sweep.sh passes; sweep verified — no bare 127.0.0.1: port bindings remain in community extensions.