Respect charm channel in air-gapped environment

Also, there are other issues for charmcraft:
* https://github.com/canonical/charmcraft/issues/37
* https://github.com/canonical/charmcraft/issues/1101

From the charmhub side, there is:
* https://github.com/canonical/charmhub.io/issues/727

If you are going to have one branch per channel, why not encode that information into your version file?

You can do:
(git describe --dirty --tags | tr '\n' ' ' ; git branch --show-current) > version

Which gives something like:

v3.1.6-81-g3782cb5194 3.1

And that will give you the branch that this was developed on, and the exact git sha where it was developed.

We already provide a way for you to have the charm author defined information available in 'version' to be displayed in status, I'm not sure we need another way to do that.

I disagree with the general philosophy that "deploying from a downloaded snap should be equivalent to deploying from the store", because we can't do updates or tracking, etc.

I understand that ultimately you want to be able to understand that at this site would be equivalent if you could have deployed from the store.
However, I really don't think we should be encoding that into the charm binary itself. Because how you get it from the store can very easily change with time, while the charm binary itself cannot.

If you published revision 24 to latest/edge you could then promote it to latest/stable, and/or expose it as 3.1/stable, all of which would be valid sources for that revision 24, but would have different implications for 'juju refresh'.

If the goal is to be able to reverse engineer "what was deployed there", we have version for that, and if your tagging structure is such that it isn't enough for you to actually define what is there and you need branch, then include that in your version.

It is incorrect to say that I got 'revision 24 but I got it from latest/edge' meaning something different than getting 'revision 24 from 3.1/stable'

I would be a bit more ok if you wanted to just record that in current juju state (deploy ./foobar.charm but pretend it came from the store at revision X and channel Y/R)

But if you want the actual binary that you deploy to be the binary that you get from the store, then it shouldn't be modified.