Be consistent about choice of TTLCache keys in Director stat utilities

[jhiemstrawisc]

How did I discover this subtle issue? I asked Claude "Please explain the stat utility's TTLCache model as though it were being whiteboarded out amongst colleagues" and its response was "I confirmed your bug!" and then spat out this issue.

The bug is that we use a different values for keys to instantiate TTLCache entries than we do to access the values we've stored. Compare how we (previously) set these TTLCache keys with where we use the keys for lookups:

pelican/director/sort_algorithms.go

Line 292 in 135bafc

avail, ok := availMap[ad.Name]

Not at all what I asked the AI to do, but helpful none the less.

P.S. I'll note that I don't love the unit tests here --> they're narrow in scope and don't actually test that multiple pieces of code are correctly strung together (they merely assert we're using a specific key in the TTLCache). However, they're better than nothing and I wanted to have something since we're hoping to test this stat future in the coming week. As @patrickbrophy noted, this bug is actually a solid argument for a strong type system in this area of code, but I'm okay with the quick-and-dirty fix for now.

If you'd like check that these tests would have failed with the previous bug, I recommend:

# Stage but do not commit the revert in your index (i.e. don't modify HEAD)
git revert --no-commit 13968f0a8996e55e40900efce3c499e06f0e3a6f

# Run the tests, observe failure

# Wipe the index to point back at HEAD
git reset --hard

[patrickbrophy]

LGTM