Enable storage retention for gem

[pinguinfuss]

Refs #306.

Registers gem for storage.retention.

Gems are stored under the name from the gem filename, and purl keeps gem names as written. Package rules match the name as published, case included. Packages that git-pkgs wrote as rubygems fall under the gem rules too.

The filename parser splits platforms that end in a number (universal-darwin-22) at the wrong hyphen. It files those gems under a package like sorbet-static-0.5.11002-universal-darwin, so package rules don't reach them. The gem rule and default still do. The docs row says so until the parser is fixed.

The mirror can't fetch gems today (it asks the resolver for rubygems, see #415), so there's no mirror test.

[andrew]

Same as #452: rather than documenting the universal-darwin-22 split as a limitation, please fix parseGemFilename in internal/handler/gem.go. It splits at the last hyphen followed by a digit, so sorbet-static-0.5.11002-universal-darwin-22.gem is stored as package sorbet-static-0.5.11002-universal-darwin, which is wrong for cooldown, policy and listings as well as retention rules. Platforms ending in a number are common (universal-java-17, arm64-darwin-23).

Gem names can contain hyphens, so splitting at the first hyphen followed by a digit is the better heuristic: it handles every platform suffix and only misreads names with a -<digit> segment, which are far rarer. Please add test cases for platform and plain gems.

With that in, the caveat in the gem docs row and the parser sentence in the init comment can go. The fix can be in this PR or a separate one merged first. This will also need rebasing for the docs/configuration.md table once the neighbouring retention PRs are in.

[pinguinfuss]

Fixed in 680a2da: parseGemFilename now splits at the first hyphen followed by a digit. Tests cover universal-darwin-22, universal-java-17, arm64-darwin-23, x64-mingw-ucrt, a prerelease and plain gems, and the caveat is gone from the docs and the init comment. Rows cached under the old wrong names stay where they are; the next download stores the gem under the right package, and the old row ages out like any other unused one.