STAC-25520 Remove dead S3 binary publishing script

[LouisParkin]

The GitLab pipeline had a publish_binaries job that uploaded the process-agent binary and ebpf-object-files.tar.gz to s3://stackstate-process-agent-2-test/binaries/<branch>/ with --acl public-read. It was retired with the rest of the GitLab config, leaving packaging/publish_staging_package.sh behind with no caller.

I picked this up as a GitLab → GitHub parity gap under STAC-25142 / STAC-25520 — the question was whether to reimplement it. I do not think we should, and I would rather delete it than leave a dead script implying the capability exists.

Why I believe nothing consumes it

stackstate-agent's omnibus build is the only consumer I could find. omnibus/config/software/stackstate-process-agent.rb curls the binary straight back out of this bucket. But it is only declared as a dependency on origin/master:

branch	last commit	declares the omnibus dependency
origin/master	2024-08-27	yes
stackstate-7.71.2 (production)	current	no
stackstate-7.78.2 (default)	current	no

Omnibus only builds declared dependencies, so on the active branches that software def is orphaned and never runs. That fits the shape of the component — the standalone process-agent ships as a Kubernetes image now, which is why the image is stackstate-k8s-process-agent.

beest does not use it. I checked StackVista/beest directly: no reference to the bucket. It resolves a branch to an 8-char short SHA via helpers/get-latest-short-sha.sh and uses that as the image tag (process_agent_image_tag), so it consumes the registry, not S3. That also lines up neatly with the 8-character tags this CI publishes.

Nothing in this repo calls it, and no AWS credentials are provisioned to this repo in pulumi-infra — so restoring the capability would mean granting new ones, plus re-establishing a public-read bucket of build artifacts, for something with no consumer.

Empirically, S3 publishing has been off since the GitLab pipeline was retired, with no reported breakage.

One caveat worth stating plainly

I could not run an exhaustive org-wide sweep. GitHub code search returns a zero count for this token even on control queries where I know the string exists, so it is non-functional here rather than genuinely empty — I discarded that result instead of treating it as evidence. My conclusion rests on the repos I could read directly (stackstate-agent, beest, this one) plus the pulumi-infra credential check. If you know of a consumer outside those, say so and I will restore it instead. It is one git revert away.

Also noticed, deliberately not in this PR

packaging/ has more GitLab-era residue that is now unreferenced: commit-or-tag.sh (pure GitLab CI commit variables), publish_image.sh (superseded by the publish jobs in ci.yml), and build-and-label.sh + oci-labels.sh (superseded by image-pipeline's apply-oci-labels action, though build-and-label.sh says it is kept for local use). I left those alone to keep this PR to its ticket — happy to sweep them in a follow-up if you want.