Download and verify release bundles securely

[Staphylococcus]

Parent: #91

Depends on: #94, #95

Outcome

Provide a testable acquisition pipeline that resolves one eligible release, stages its assets, and proves the bundle safe and authentic enough for the existing GitHub release trust model without applying it.

Scope

• Extend GitHub release metadata with asset ID, name, size, digest, and download URL.
• Select exactly one x86_64-unknown-linux-musl archive and one sha256sums.txt; reject missing or duplicate matches.
• Resolve the release tag reference to an immutable commit, following annotated tags with a bounded depth.
• Restrict requests to the LG Buddy GitHub repository, HTTPS, and an explicit GitHub release-asset redirect policy.
• Apply connection, request, redirect, and byte-size limits.
• Stage under the user cache with restrictive directory and file permissions.
• Exclude concurrent acquisitions with a process-lifetime filesystem lock.
• Verify the GitHub asset digest, the published checksum entry, and agreement between them.
• Reject absolute paths, traversal, links, devices, unexpected roots, duplicate entries, and unexpected bundle layouts before extraction.
• Verify the bundle manifest and extracted binary version, channel, target, and tagged commit.
• Remove incomplete staging after success or failure.

Acceptance criteria

• Focused tests cover missing, duplicate, wrong-target, oversized, malformed, interrupted, and digest-mismatched assets.
• Archive traversal, link, layout, manifest, version, channel, target, and commit mismatches are rejected.
• Concurrent attempts fail without disturbing the active staging directory.
• No installer or extracted executable runs until every verification step succeeds.
• Existing release discovery/cache behavior remains covered.

Out of scope

• Invoking install.sh.
• User confirmation and sudo UX.
• Independent signing or attestations.