2.36.0: enormous numbers of loose objects after enabling partial clone filter: why? how to clean up?

[Nix <nix@esperi.org.uk>]

So I turned on promisor remotes for my local Chromium tree last week:
the relevant remote now has partialclonefilter = blob:limit=10m. I
wanted to save a bit of space (well, OK, I was hoping for a lot).

This turned out to be... a bad idea. The first fetch after that exploded
some 45GiB of loose objects (nearly six million of them). I spotted an
ancient historical config option gc.pruneExpire=never and removed it:
that would explain the worst of the accumulation, if the files weren't
all dated at around the time of my first pull after turning on partial
clone.

A git repack -ad, git prune --expire=now, and similar expiry of all the
reflogs has got them down to a mere 112957 objects, 597304 kilobytes (!)
but I can't get the count lower than that, despite deleting every remote
(to get rid of the remote-tracking branches) and doing a full repack
(non-aggressive), prune, and a git prune-packed (which had no effect at
all). I've done not a great deal of work in this tree and no rebases:
there should be hardly any legitimate loose objects, I'd have thought.

Indeed, git fsck --verbose --name-objects shows that all these objects
are referenced, mostly in a few fairly recent branches. They also
clearly reside upstream, in the remote-tracking branches. So... why is
git repack refusing to pack them? Is there any way to find out? It's
fairly opaque in its decisions, which usually I don't worry about, but
this space bloat is kind of ridiculous.

(There are no alternates or anything like that pointing at this repo, so
it's not that.)

-- 
NULL && (void)