fix: share compiled method allowlists across authority login sessions

[lthibault]

Why

KeyMethodAuthorization::authorize rebuilds a fresh runtime Allowlist from
the recipient's compiled method profile on every successful login.

PR #617 removes the earlier recipients × methods amplification during policy
compilation, but this separate, pre-existing path remains:

• a caller obtains an AuthorityServer::guard terminal;
• the terminal is reusable rather than single-use;
• each successful login walks the full method profile and allocates another
  HashSet<(u64, u16)>; and
• sessions can be retained, so memory grows with logins × methods.

The authenticated-VAT serving path already bounds concurrent sessions with a
ConnectionBudget and makes each per-connection terminal single-use. The
generic AuthorityServer::guard path has neither bound.

This is a guest-to-host availability risk for large profiles. It is not caused
by #617 and should not expand that PR.

Proposed fix

Let the membrane Allowlist consume or reference the already-compiled shared
method set rather than rebuilding an equivalent set for every login.

One candidate is an Allowlist::from_shared(Rc<HashSet<MethodKey>>) constructor
whose Policy::check performs membership against MethodKey. Preserve
Policy::allowlist_keys behavior so membrane collapse remains correct.

Treat terminal reuse and connection/session budgeting as a related defense in
depth question, not as a substitute for removing the per-login deep copy.

Acceptance criteria

• A successful authority login does not deep-copy the recipient's full
  method profile.
• Multiple live sessions for the same recipient share one immutable method
  set while retaining independent session/capability lifecycle.
• Policy::check and Policy::allowlist_keys preserve existing allowlist
  semantics and membrane-collapse behavior.
• Targeted recipient revocation still invalidates every already-issued
  session for that recipient.
• Epoch expiry still invalidates sessions at the Atom boundary.
• A regression test logs in repeatedly with a large profile and proves the
  method allocation is shared rather than rebuilt.
• Existing authority, membrane, authenticated-VAT, and Chess authorization
  tests pass.

Relevant code

• crates/authority/src/issuer.rs: KeyMethodAuthorization::authorize
• crates/authority/src/issuer.rs: AuthorityServer::guard
• crates/membrane/src/lib.rs: Allowlist
• crates/rpc/src/vat_listener.rs: authenticated-VAT single-use terminal and
  connection-budget handling