Add forgeclient: ingot's Forge client as a shared module

[Peeja]

[From Claude:]

Stacked on #7 (which stacks on #6); merge in that order. This is the client half of the consolidation: ingot's carried copies of guppy's Forge client become a shared module, and ingot consumes them like any other in-repo module. Two commits.

What changes

#	Commit	What
1	Add forgeclient: the Forge protocol client as its own module	ingot/forgeclient → forgeclient/ (module github.com/fil-forge/forge/forgeclient), ingot/tokenstore → forgeclient/tokenstore, ingot/blockstore/locator → forgeclient/locator, and ingot/internal/ucanexec → internal/ucanexec (both the client and ingot's read path import it, and a module-level internal/ cannot be shared across modules). A pure move: import paths, gofmt's import ordering and the package docs are the only edits. ingot requires the module through a replace; the module joins go.work, the CI matrix, the root Makefile, the Dockerfile's manifest COPYs and smelt's sharedDirs.
2	forgeclient/tokenstore: adopt guppy's store tests	guppy's pkg/tokenstore/store_test.go (270 lines) with its import path changed and nothing else. The store never had tests on the ingot side.

Why ingot's copy and not guppy's

The plan's Phase 4 assumed guppy's pkg/client was the source of truth and ingot's copy a trimmed fork. Measuring the two (forgeclient-divergence.md on the POC branch) shows the flow reversed: guppy's client has not changed since 2026-06-19, while ingot's gained the per-call proof store (WithProofStore), an explicit Content-Length on the blob PUT, deferred accept (WithConclude(false) / BlobConclude), BlobAbort and BlobRemove, and dropped the hard requirement that the accept receipt carry a /pdp/accept invocation. tokenstore is byte-identical between the two. So the shared module is extracted from ingot. What guppy has that ingot dropped — retrieval, spaces, progress/stall readers, /blob/replicate (the sole user of the pre-ucantone go-ucanto/go-libstoracha stack) — is not re-added here.

Deliberately not in this PR

• guppy is untouched (no archival, no import of forgeclient); smelt's e2e/compat suites still drive the network through the guppy container image (Phase 5 of the plan).
• No API changes to the client: BlobAdd(ctx, space, content, ...) keeps ingot's signature, logger injection is ingot's WithLogger, and the locator keeps its go-log package logger (still named client/dagservice, from guppy).
• No tags and no API-stability promise for forgeclient.

Dependencies

forgeclient → protocol, internal (ucanexec), attestation (the login flow's attest command and did:mailto helpers), indexing-service (the locator's query client), ucantone — the in-repo requires through replace directives, like every other module here. ingot's go.mod gains the forgeclient require and replace; internal/go.mod only sees cbor-gen become a direct dependency.

Verification (GOWORK=off)

• forgeclient, internal, ingot, smelt: build, vet, and go mod tidy is a no-op.
• forgeclient's tests (accounts, proofstore, the adopted tokenstore suite), ingot's unit tests and smelt's pkg/workspace tests pass.
• .github/scripts/check-replaces.sh passes; workspace-mode builds pass for the four modules.
• The Dockerfile change (one more manifest COPY) is exercised by the stack job's ingot image build on this PR.

Reviewing

Commit 1 with git show -M --stat: 21 renames; the non-rename hunks are the import paths in ingot's eight importing files, the new forgeclient/go.mod and go.sum, the registration edits, and doc text. Commit 2 is one file — diff it against fil-forge/guppy@e87812b:pkg/tokenstore/store_test.go.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CGAGAib517Ae1kg8SCdcEt

---

Generated by Claude Code