🟠 HIGH: Refactor GroupViewModel (1,886 lines) into smaller services

## Problem

`GroupViewModel.swift` is a **1,886-line god object** that violates single responsibility principle, mixing:

- Key exchange protocol handling
- P2P message routing
- Peer discovery management
- Stream management
- UI state management
- Cryptographic operations

## Impact

- **Maintainability**: Nearly impossible to modify safely
- **Testability**: Cannot unit test individual concerns
- **Performance**: Holds too much state in memory
- **Bugs**: High risk of regressions

## Proposed Decomposition

```
GroupViewModel (1,886 lines) → Split into:
├── GroupChatViewModel (~200 lines) - UI state, message display
├── GroupMembershipService (~300 lines) - Peer management
├── P2PKeyExchangeService (~400 lines) - Key exchange protocol
├── GroupMessageService (~300 lines) - Message sending/receiving
└── GroupStreamService (~200 lines) - Stream lifecycle
```

## Acceptance Criteria

- [ ] GroupViewModel reduced to <300 lines (UI state only)
- [ ] Each extracted service has single responsibility
- [ ] All services are protocol-based for testability
- [ ] Unit tests for each extracted service
- [ ] No functionality regression

Start by reading GroupViewModel.swift and map the responsibilities listed in the issue to the proposed services. Use the acceptance criteria to define completion: GroupViewModel under 300 lines, protocol-based extracted services, unit tests for each service, and no functionality regression.

Written by the indexing model from the issue text.