1:N authorization: max-viewers, viewer-only invitations, per-peer revocation, focus policy

[FelineStateMachine]

Part of #74. References @ 17980ad. Depends on the protocol issue; pairs with the registry issue.

Grants are already per-peer (InvitationGrants, crates/sigil-protocol/src/invitation.rs:23-58; enrollment ledger in crates/sigil-host/src/authorization.rs). This issue scales the surrounding policy from one enrolled peer to many.

• Config: max_viewers (bounded, validated) and a focus-arbitration policy knob. Ship one default: focus is granted to the first input-capable requester when free; taking occupied focus requires the holder to release, except that a configured owner peer may preempt. Preemption-by-anyone and queueing are explicitly out of scope.
• Invitation flow: issuing view-only invitations must be a first-class path in the appliance CLI and Decky UI, not a hand-edited bitfield.
• Revocation: appliance CLI gains list-peers, revoke-peer, and revoke-capability (e.g. strip gamepad from a peer). Revoking an input capability from the current focus holder revokes focus and neutralizes input immediately; revoking view drops the session. Runtime revocation must take effect without a daemon restart, which means the accept-path authorization snapshot gains an invalidation path (note the flock coupling in review issue [architectural benefit] Make the daemon the single writer of authorization state #68 before building on it).
• Replay ledger and enrollment state sizing: bounded growth with N peers, and enrollment reset semantics reviewed for multi-peer (does reset drop all peers or one; make it explicit in the CLI surface).
• Audit trail: focus grants/revocations and connects/disconnects logged with peer identity, consistent with the existing invitation-evidence approach (PR Harden invitation acceptance evidence #19).