chore: extract 3 small fixes from closed #1664

[HongmingWang-Rabbit]

Three small, non-overlapping fixes extracted from closed PR #1664. Bundled because each fix is tiny, they touch independent files, and they share the same provenance (all unblocks or stability tweaks the original PR carried alongside bigger changes that won't ship).

Fix 1 — canvas ContextMenu.tsx: React error #185 (infinite snapshot loop)

ContextMenu previously derived the "does this node have children?" flag via a useMemo over a new array returned by (s) => s.nodes. The useMemo was stable across renders, but the selector itself returned a fresh reference every time an unrelated field in the canvas store changed, which Zustand's useSyncExternalStore saw as "snapshot changed" and scheduled a re-render -> another selector call -> another fresh array -> loop -> React error #185 on some prod sessions.

The new selector hashes down to a boolean (s.nodes.some(...)). Booleans compare stably with Object.is, so the snapshot is steady. The delete handler still needs the actual child nodes to prompt the user, so it reads them once via useCanvasStore.getState().nodes.filter(...) at click time, off the render path.

Fix 2 — workspace-server a2a_proxy SSRF bypass for local-docker

resolveAgentURL rewrites http://127.0.0.1:<port> to http://ws-<id>:8000 when the platform itself runs in Docker (Docker-bridge hostname). The rewritten URL then resolves to 172.18.0.x, which the SSRF guard blocks as a private IP — stranding A2A in local-docker dev.

The fix adds isInternalDockerCall and skips the SSRF guard for that path. Two narrow cases trigger the bypass:

• The 127.0.0.1 -> InternalURL rewrite (new URL came from our own provisioner, trusted).
• URLs already starting with http://ws- under platformInDocker.

SaaS safety: the ws-* branch is gated on !saasMode(). In SaaS the workspace registry is remote and an attacker-controlled registration could claim a ws-* hostname that resolves to a sensitive VPC IP; leaving the SSRF guard on there is correct. Local-docker is a trusted single-host setup where ws-* comes from our own compose/bridge network and the relaxation is safe.

Fix 3 — workspace-server Dockerfile: dynamic Docker socket GID + gosu/su-exec entrypoint

The platform binary needs the host docker socket to provision workspaces, but the socket's group varies between hosts (Colima ~= 101, Linux ~= 999, etc.). Hard-coding a GID breaks on the other platform.

The new entrypoint.sh:

1. Reads the docker.sock group GID with stat.
2. Creates a matching docker group inside the container and adds platform to it.
3. Falls back to the root group only if the socket is owned by GID 0.
4. exec su-exec platform /platform "$@" — drops privileges before running the binary.

Non-root runtime is preserved. Only the entrypoint runs as root long enough to adjust group membership.

Test plan

• cd workspace-server && go build ./... clean
• cd workspace-server && go test ./internal/handlers/ -count=1 -run "TestProxyA2A|TestResolveAgentURL|TestIsSafeURL|TestIsPrivateOrMetadataIP" — 14 failures, all pre-existing on main (DNS-lookup + sqlmock regex drift, unrelated to this PR; same count and same names before/after the change)
• npx tsc --noEmit on canvas — no new errors in ContextMenu.tsx
• Manual: local-docker dev still resolves A2A to ws- without SSRF rejection
• Manual: platform container on Colima can docker ps via mounted socket
• Manual: canvas no longer throws React fix(security): gate GET /approvals/pending behind AdminAuth (#180) #185 with mixed parent/child workspaces

🤖 Generated with Claude Code