Separate P2P node private key

# Separate P2P Node Key from Consensus Validator Key

## Summary

This proposal separates the P2P network identity key from the consensus validator signing key by introducing a dedicated `p2p_key.json` file alongside the existing `priv_validator_key.json`.

## Motivation

Currently, the same private key is used for both:
1. **P2P network identity** - Establishing and authenticating peer connections
2. **Consensus operations** - Signing proposals, votes, and other consensus messages

This coupling creates operational challenges and security limitations that prevent best practices for key management in production environments.

## Benefits

### 1. Improved Operational Security

**Problem**: Using the same key for both P2P and consensus means:
- The signing key must be directly accessible by the node process
- Any compromise of the P2P layer exposes the consensus signing key
- No separation of concerns between network identity and validator authority

**Solution**: With separate keys:
- The P2P key can be stored on the node with standard file permissions
- The consensus key can be isolated with stricter access controls
- Network-level attacks don't directly threaten consensus signing capabilities
- Reduced blast radius in case of compromise

### 2. Flexible Key Rotation

**Problem**: Rotating keys currently requires:
- Changing both network identity and validator identity simultaneously
- Coordination across the entire network
- Potential disruption to both P2P connectivity and consensus participation

**Solution**: With separate keys, operators can:
- **Rotate P2P keys independently** without affecting validator identity
- Change network identity if a node is being DDoS'd
- Migrate to new infrastructure without validator downtime
- Rotate P2P keys on a regular schedule as a security best practice
- **Rotate consensus keys independently** without changing network identity
- Update validator signing keys per security policy
- Maintain stable P2P connections during key rotation

Example scenarios:
```bash
# Rotate only the P2P key (no consensus impact) and extract just the p2p key file for use.
$ emerald init
```

# Remote Signer Integration (Critical Path)

Problem: The current architecture blocks integration with remote signing solutions like:
- Hardware Security Modules (HSMs)
- https://github.com/iqlusioninc/tmkms (Tendermint KMS)
- Cloud KMS services (AWS KMS, GCP KMS, Azure Key Vault)
- Air-gapped signing infrastructure

Solution: Separating keys enables the path to remote signing:

```
┌─────────────────────────────────────────────────────────────┐
│ Validator Node │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ │ │ │ │
│ │ P2P Layer │◄───────────────────┤ p2p_key.json│ │
│ │ │ (local access) │ │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ │
│ │ │ Network/IPC │
│ │ Consensus │◄──────────────────────────────────────────┼─────► Remote Signer
│ │ │ (gRPC/Unix socket) │ (HSM/KMS/tmkms)
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
```

This separation is a prerequisite for implementing remote signing because:
- The P2P key must remain on the node for real-time network operations
- The consensus key can be moved to secure remote infrastructure
- The node can operate without direct access to consensus signing material
- Supports compliance requirements for key isolation

4. Operational Flexibility

Additional operational benefits:
- Infrastructure Migration: Move a validator to new hardware without changing its network identity
- Multi-Region Deployment: Run backup nodes with the same P2P identity but different consensus keys
- Testing: Use production P2P keys in staging environments with test consensus keys
- Audit Trail: Separate key materials make it easier to track and audit key usage patterns

Implementation

File Structure

~/.malachite/config/
├── config.toml
├── genesis.json
├── priv_validator_key.json # Consensus signing key
└── p2p_key.json # P2P network identity key (NEW)