Publish D2-compatible amt-verify image

[allyblockcast]

Summary

• add --packet-count and D2-compatible top-level JSON counters while preserving the existing JSON fields
• add a tested Linux amd64 amt-verify container build
• publish commit-pinned images to GHCR from the source branch and main

Verification

• CARGO_HOME=/runtime-cache/tmp/opencode/cargo-home cargo test --no-default-features --features native (119 unit tests plus all native integration tests passed; 2 staging tests ignored)
• docker build --platform linux/amd64 -t amt-verify:b15657 .
• docker run --rm amt-verify:b15657 --help contains --relay, --port, --source, --group, --no-driad, --family, --timeout, --packet-count, and --json

Source

The successor is based directly on immutable commit 255b16b3ad16e80d1b3e64a09d1a023fd1b35328; the only runtime behavior change is bounded multi-packet accounting required by the D2 probe.

Paperclip: https://paperclip.blockcast.net/BLO/issues/BLO-15657

[allyblockcast]

🔗 Paperclip issue: BLO-15657

[allyblockcast]

🔗 Paperclip issue: BLO-15657

[allyblockcast]

@ally Please review the D2 contract specifically: --packet-count collection semantics, compatibility of the additive JSON counters with onprem-k8s PR #1326, and the Linux amd64 container/publish workflow. Local Rust tests and container --help smoke are green; anonymous GHCR pull is tracked separately because first-package visibility defaulted private.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.

Critical Issues (1)

• [gstack/review, native-codex] .github/workflows/publish-amt-verify.yml:5,28-30 — the workflow triggers on push to both main and this feature branch (blo-15657-amt-verify-image), but the tags: list is unconditional — every push to the feature branch also re-publishes the mutable ghcr.io/blockcast/amt-verify:main tag, not just the sha-pinned tag. Any consumer pulling :main would get whatever was last pushed to the feature branch instead of an actually-merged commit. The PR description itself only promises "commit-pinned images ... from the source branch and main" — the floating :main tag should only be pushed when github.ref == 'refs/heads/main' (e.g. gate the second tag line with if: github.ref == 'refs/heads/main' on a separate step, or use docker/metadata-action to compute tags conditionally).

Important Issues (1)

• [pr-review-toolkit:pr-test-analyzer] tests/cli_json.rs:45-46 — the new --packet-count multi-packet accounting loop in src/bin/amt-verify.rs (the while packet_count < args.packet_count block) has no test exercising packet_count > 1. The only assertions touching the new fields (packet_count, byte_count) are against the default single-packet path, so the actual new behavior (looping recv_first_matching and accumulating counts across multiple packets) is unverified.

Suggestions (1)

• [pr-review-toolkit:code-reviewer] .github/workflows/publish-amt-verify.yml:16-23 — third-party actions (docker/setup-buildx-action@v3, docker/login-action@v3, docker/build-push-action@v6) are pinned to version tags rather than commit SHAs. Since this workflow has packages: write and pushes to GHCR, pinning to SHA would harden against upstream tag-mutation supply-chain risk.

Strengths

• Container runs as non-root (USER 65532:65532) and the Rust build stage is cleanly separated from the slim runtime image.
• New OneshotReport fields (packet_count, byte_count, first_data) are additive — existing JSON consumers keep working, matching the PR's stated backward-compatibility goal.
• The multi-packet loop runs before finish_gateway's leave/teardown sequence, so default (packet_count=1) behavior and the existing shutdown test are unaffected.

Recommended Action

1. Fix the Critical :main tag drift before this publishes an unreviewed image as "main".
2. Add a test covering --packet-count 2+ end to end.
3. Consider SHA-pinning the GHCR publish actions opportunistically.

Reviewed head: 0867616