Add support for content addressable gems

This issue will track the progress of implementing content addressable gems and skinny binary support. Sub issues will be created that will provide more detail on implementation in the CLI and server.

Background & Motivation

Today, precompiled gems ship as "fat" binaries: a single .gem (e.g. my_gem-1.1.0-arm64-darwin.gem) bundles a native binary for every supported Ruby version, even though a consumer only ever uses one.

To better support gems with native extensions, RubyGems/RubyGems.org teams agreed on a design to support "skinny" binaries instead — one small artifact per Ruby ABI — making installs faster (smaller downloads) and simplifying how maintainers build and ship precompiled gems.

The naming blocker

Gem files are named <gem name>-<version>-<platform>.gem with a uniqueness constraint. Multiple skinny binaries for the same name, version, and platform would collide.

To fix this, we replace the platform string with an 8-character checksum derived from the file contents (content-addressable naming):

my_gem-1.1.0-arm64-darwin.gem    # current
my_gem-1.1.0-bb65ajk8.gem        # content-addressable

An alternative is to encode Ruby ABI + platform tags directly into the filename. That solves the same collision problem, but it keeps growing the name as we add more distinguishing dimensions (ABI, platform, and later system requirements, Ruby engine, etc.). Decoupling that metadata from the name entirely — moving it into compact-index requirements — keeps gem names short and fixed-length, and lets us add new matching dimensions later without another naming-scheme change.

No files, tests, or entry points are identified in the issue. Start by following the planned CLI and server sub-issues, then review how compact-index requirements can represent ABI and platform metadata; done means supporting content-addressable naming and skinny binary artifacts without filename collisions.