Infrastructure authentication

# Background

Authentication is currently entirely unaddressed in both `Argus` (downloads) and `Colossus` (uploads), which is an obvious problem. Here are some of the personae types we currently have contemplated across a range of proposals

1. **Channel collaborators:** currently just members
2. **Channel owner:** content WG worker, lead or raw member
3. **Content lead:** content WG worker
4. **Council member:** currently just members
5. **Curator group member:** content WG worker
6. **NFT owner:** member
7. **CRT owner:** member
8. **Gateway user:** need not have any on-chain footprint
9. **Raw member**

The primary complication is how to allow low friction authentication for consumer use cases where it is costly for users to have their wallet and signer pop up on every occasion there is an interaction with `Argus` and `Colossus`. It's much less of a concern for paid and sophisticated actors like group members, leads and council members, but making their life less miserable certainly has some value as well.

# Proposal

Looking at the cases above, there are basically three root level authorities for each persona

1. The gateway for the gateway user.
2. The underlying member powering the relevant role/asset ownership.

For the first one, authentication can just follow some conventional Web2 standard for centralised authentication, e.g. like JWT. For the second one, using the controller account is the natural mechanism, however that will be a very bad consumer experience e.g. for 2,6,7, and 9 above. The natural solution is to allow members to publish long running session keys on-chain, and then infrastructure can maintain a list of such keys for each membership, and allow using them. Obviously, since a single member can act in all of these roles, an actor would authenticate in the appropriate personae, not directly as a member, but the infrastructure would be able to resolve the correct member and set of permissible session keys. The information is not stored in storage state, but just indexed in metaprotocol layer. The benefit of this is that a member can do this one time, e.g. when creating a membership, and then this can be reused. In a browser context, the private key can be held in local storage, and if the user goes to a new browser or deletes history, a new key has to be added to the membership. However, when `Orion` v2 (the Atlas backend) allows private user state, as is planned, then recovering the key across apps and devices should not be an issue any longer.

This is an imperfect solution, at least in while we have no `Orion` v2, however I don't see a better alternative. If no better alternative can be conjured up, I suggest next step is to define a small standard for this in a standalone issue, I suggest initial requirements:

- should be transported both over normal member remarks, but also during membership creation and updating.
- should allow both creating and revoking prior keys,but more than one active key simultaneously should be fine.
- should allow publishing public keys which have limited and unlimited lifetime.

anything else?