fix(code-server): stop pinning both address families on 8080

[robmry]

• Follows docker/sandboxes#4994, which changed the default protocol for port bindings to tcp4 (for sbx v0.40)
• Reported as Can't use IPv6 to connect to an IPv4-only server in the sandbox sbx-releases#342

code-server runs code-server --bind-addr 0.0.0.0:8080 inside the sandbox — IPv4 only — while the kit pinned protocol: tcp, which publishes both address families. On a host whose resolver answers localhost with ::1 first, opening http://localhost:<port>/ therefore reached the sandbox over IPv6, where nothing was listening, and the connection was accepted and then reset. That is a dead end no client recovers from, unlike a refusal, and it is the exact complaint behind docker/sbx-releases#342.

docker/sandboxes#4994 addresses that consumer-side, by publishing a single address family when no protocol is named — but a kit that spells out protocol: tcp opts back out of it, so this kit would keep the broken behaviour. Since the spec accepts only "", "tcp" and "udp" (until #163 is merged), omitting the field is how a kit stops demanding both, so the line is dropped and a comment records why it must stay dropped.

Safe to land before the consumer change ships

This kit goes live on merge, while docker/sandboxes#4994 is not in a release yet. Both cases are fine:

• an sbx that resolves an empty protocol to dual-stack tcp reproduces exactly what the pinned value did, so nothing regresses for anyone running one today;
• an sbx that resolves it to one family fixes the dead end, and this kit picks that up with no further edit.

That is also why none of the comments here name a version or state what the default is: the same spec is read by consumers on both sides of that change.

Spec documentation

The spec asserted an equivalence between an empty protocol and tcp in two places. Both now describe the contract instead — empty defers to the consumer, naming a protocol asks for both families and so needs a service listening on IPv6 — without claiming what any particular consumer does:

• spec/types.go on PublishedPort.Protocol
• the ports: example in spec/SPEC-v2.md

The validation rule is unchanged: protocol is still one of "", tcp, udp.

Other kits

I checked every kit that declares ports. codex-app-server also pins protocol: tcp, for sshd on 22 — left alone deliberately, since sshd listens on both families by default, so dual-stack publishing is correct there. nanoclaw omits the protocol already and picks up the new default with no change.

_{🤖 Raised by Claude Code on behalf of @robmry.}