feat(tlon): add group-level authorization inheritance with channel overrides

[kennyrowe]

Problem

Operators naturally think in terms of group trust ("this group is trusted"), but the durable authorization model currently lives primarily at the channel level. That creates a mismatch between:

• operator intent
• config shape
• runtime behavior

In practice this makes it easy to confuse:

• discovery scope (groupChannels)
• authorization scope (channelRules)
• social participation behavior (when the bot should actually speak)

A real example: an operator expressed "the group as a whole is trusted," but the implementation path pushed toward channel-specific settings like channelRules.<channel>.mode = open or restricted + allowedShips. That works mechanically, but it forces the operator to think in the wrong abstraction.

Proposal

Support group-level authorization inheritance with channel-level overrides.

Suggested resolution order:

1. authorization.channelRules[channelNest]
2. authorization.groupRules[~host/group-slug]
3. default restricted behavior

That would let operators express the common case directly:

• trust this whole group by default
• override specific channels only when needed

Why this helps

This matches how people actually reason about trust in Tlon:

• “this whole group is trusted”
• “except maybe this one channel”

instead of requiring trust to be encoded first at the individual channel layer.

UX / terminology follow-up

The current open vs restricted terminology is technically understandable but still easy to misread when configuring authorization.

At minimum, it would help to surface explanatory language such as:

• open → anyone in this channel/group can validly engage the bot
• restricted → only listed ships are pre-authorized

The distinction is especially important because authorization and social behavior are separate:

• open should not imply the bot becomes chatty
• restricted should not be the only way to model trust

Local prototype

I implemented this locally in a downstream Tlon plugin fork as:

• authorization.groupRules keyed by ~host/group-slug
• channelRules taking precedence over inherited group rules
• fallback to restricted/default behavior

Local prototype commit:

• 6bcb53487 — tlon: add group rule inheritance

The code change was small; the bigger value was clarifying the trust model.

If useful, I can also turn the local prototype into an upstream PR.