build(deps): bump swarf for the firehose fixes; build the cmd package in Docker

[Peeja]

[From Claude:]

Two independent commits. Happy to split them if you'd rather review them apart.

1. 0cd1b4a — bump swarf to 1778ec0

The pin was d5d1a0a5 from 2026-08-21 (ci: request a dev deploy after publishing), nine commits behind swarf's main. Three of those nine are firehose fixes, and hilt reaches them through swarf/pkg/client in non-test code — pkg/rpc/service/bucket/service.go and pkg/api/service/accesskey/service.go:

#17	raise the firehose client's SSE scanner limit; read the stream through one sse.Scanner
#18	bound the event MaxEventBytes names, and report the service's error events
#19	report a failed firehose stream to the caller of the handler

Before #19 a failed stream was swallowed — the caller saw a stream that had simply stopped producing.

2. 4857e93 — go build ./cmd, not ./cmd/main.go

Both Dockerfile stages named a file. From go help build:

If the arguments to build are a list of .go files from a single directory, build treats them as a list of source files specifying a single package.

One file listed, one file compiled. Any second file added to package main is silently dropped, and the build fails on the first symbol crossing between them.

Latent today only because cmd/ holds exactly one .go file. cmd/client/ is a separate package and resolves normally, which is why nothing has ever noticed. Makefile already said ./cmd and needed nothing — this is the Dockerfile only.

Not hypothetical: sprue had the identical spelling, and adding a cmd/version.go there broke its container build for eighteen hours while every package-level check stayed green. Reproduced here the same way, with a throwaway second file in package main:

$ go build -o /tmp/hilt-probe ./cmd/main.go
# command-line-arguments
cmd/main.go:20:6: undefined: probeSymbol

$ go build -o /tmp/hilt-probe ./cmd
(clean)

The probe was reverted; only the Dockerfile changes here.

Verification

All with GOWORK=off:

• go build ./... — clean
• go vet ./... — clean
• go vet -tags itest ./itest — clean. Worth calling out: the tag-gated suite is where itest/stack_test.go imports swarf/pkg/client and swarf/pkg/store, so it is the only thing that compiles hilt's swarf usage in that file. go build ./... never sees it.
• go test ./... — 26 packages ok, 0 failures

Limit: Docker was unavailable in my environment, so the testcontainers-backed Postgres and OpenBao suites skipped, and neither the container build nor make itest actually ran. CI covers both.

Context

This came out of the fil-forge monorepo work — the stale pin was found while auditing in-repo dependency freshness. Related and worth knowing: ingot has weekly gomod dependabot, and in its last 100 PRs, 35 are dependabot's and zero bump a fil-forge/* module. hilt has no dependabot config at all. The cause looks like tagging — swarf, hilt and ingot each carry exactly one tag, v0.0.0, which sorts below the pseudo-version already pinned, so there is no newer version for dependabot to offer. Filed here only as context; not something this PR addresses.

Opened as a draft so nobody feels obliged to review before Petra has looked.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CGAGAib517Ae1kg8SCdcEt

---

Generated by Claude Code