refactor: remove legacy API server and localize Nix sibling deps

[Patel230]

Summary

• remove the unused legacy internal API server and its wiring from hawk
• update the changelog to reference the current daemon/version surface
• make Nix builds resolve GrayCode sibling modules locally instead of relying on stale proxy tags

Test plan

• go test ./...
• pre-push hooks (govulncheck, test, vet)

Made with Cursor

[Patel230]

Net -422 LOC and the API server + its tests are cleanly excised with no dangling references — solid. Flake.nix change makes the build hermetic against the stale Go proxy, which mirrors the Dockerfile's behavior.

Approving with one must-follow-up:

• flake.nix setupReplace (>> go.mod) is not idempotent across preBuild and overrideModAttrs.preBuild. If the flake is re-evaluated between phases, sibling replace directives will be appended twice and go mod will error. Fix by stripping existing sibling replace directives before appending, or by reading go.mod into a string, replacing via lib.replaceStrings, and writing once. Also worth a comment that dirOf assumes the github.com/<org>/<name> shape.

Smaller items:

• cmd/hawk/main.go still wires cmd.SetVersion / mcp.SetClientVersion / sandbox.ContainerImageTag = Version independently. With api.SetVersion gone, a single cmd.RegisterVersion helper would be a nice follow-up.
• Consider adding a nix flake check step to CI so future flake.nix changes are validated by more than cross-compile builds.
• CHANGELOG entry mixes two unrelated changes; either two lines or two commits for clean revert surface.

CI is green; Docker build-and-push + fuzz are still pending but unrelated to the diff.

[Patel230]

Net -422 LOC and the API server + its tests are cleanly excised with no dangling references — solid. Flake.nix change makes the build hermetic against the stale Go proxy, which mirrors the Dockerfile's behavior.

Approving with one must-follow-up:

• flake.nix setupReplace (>> go.mod) is not idempotent across preBuild and overrideModAttrs.preBuild. If the flake is re-evaluated between phases, sibling replace directives will be appended twice and go mod will error. Fix by stripping existing sibling replace directives before appending, or by reading go.mod into a string, replacing via lib.replaceStrings, and writing once. Also worth a comment that dirOf assumes the github.com/<org>/<name> shape.

Smaller items:

• cmd/hawk/main.go still wires cmd.SetVersion / mcp.SetClientVersion / sandbox.ContainerImageTag = Version independently. With api.SetVersion gone, a single cmd.RegisterVersion helper would be a nice follow-up.
• Consider adding a nix flake check step to CI so future flake.nix changes are validated by more than cross-compile builds.
• CHANGELOG entry mixes two unrelated changes; either two lines or two commits for clean revert surface.

CI is green; Docker build-and-push + fuzz are still pending but unrelated to the diff.

[Patel230]

Self-review notes (cannot self-approve or self-request-changes via gh):

Net -422 LOC and the API server + its tests are cleanly excised — solid. Flake.nix makes the build hermetic against the stale Go proxy.

Must-fix before merge:

• flake.nix setupReplace (>> go.mod) is NOT idempotent across preBuild and overrideModAttrs.preBuild. If the flake re-evaluates between phases, sibling replace directives append twice and go mod will error. Strip existing sibling replace directives before appending, or read go.mod into a string, replace via lib.replaceStrings, and write once. Also worth a comment that dirOf assumes the github.com// shape.

Smaller items:

• cmd/hawk/main.go still wires cmd.SetVersion / mcp.SetClientVersion / sandbox.ContainerImageTag = Version independently. With api.SetVersion gone, a cmd.RegisterVersion helper would be a clean follow-up.
• Add a nix flake check step to CI so future flake.nix changes are validated beyond cross-compile.
• CHANGELOG entry mixes two unrelated changes; ideally two lines or two commits for clean revert surface.

CI all green on the most recent run (Docker fuzz and builds re-triggered after this comment).