Comment 5 for bug 2045317

I'm including snapstore-server here, because there is meant to be a base automatic-detection. But when we send a request and they respond with 'no such revision', they aren't including the channel that we requested.

You can see that our initial REFRESH request does include a channel:
machine-0: 17:56:47 TRACE juju.apiserver.charms.charmhubrepo.client charmhub Refresh(charmhub.executeOne{
    ID: "",
    Name: "loki-k8s",
    Revision: (*int)(nil),
    Channel: &"edge/325",
    Base: charmhub.RefreshBase{Architecture:"amd64", Name:"", Channel:""},
    action: "install",
    instanceKey: "bf312794-0e9f-4a32-85d7-ed858b3c0425",
    fields: {"bases", "config-yaml", "download", "id", "license", "metadata-yaml", "name", "publisher", "resources", "revision", "summary", "type", "version"},
})

But the response doesn't filter to the channels that we have requested, but gives the generic "here are the public bases that are available". Which isn't useful for a lot of reasons. I believe the issue is the juju client realizes that it isn't filtered, and thus filters the response to only include what we requested, and thus cannot see a base for a channel.
(Imagine that the 'edge' channel only supports 22.04, but 'stable' only supports 20.04, Juju wants to supply the channel to charmhub if we know it, and have charmhub say 'if you are selecting edge, default to 22.04, but if you supply 'stable' then select 20.04)

I do think Juju can try to do better with the error message. But the fundamentals are that charmhub is not respecting the channel that we supplied, and thus juju can't figure out how to proceed.