Channel policy enforcement checks

I was changing the numbers of the json file for a simulated network and found myself confused on how the channel policy checks are enforced in `sim_node.rs`

after parsing the file, for each node in the channel we have this channel policy struct:
```
/// Represents one node in the channel's forwarding policy and restrictions. Note that this doesn't directly map to
/// a single concept in the protocol, a few things have been combined for the sake of simplicity. Used to manage the
/// lightning "state machine" and check that HTLCs are added in accordance of the advertised policy.
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct ChannelPolicy {
pub pubkey: PublicKey,
#[serde(default)]
pub alias: String,
pub max_htlc_count: u64,
pub max_in_flight_msat: u64,
pub min_htlc_size_msat: u64,
pub max_htlc_size_msat: u64,
pub cltv_expiry_delta: u32,
pub base_fee: u64,
pub fee_rate_prop: u64,
}
```

However the way we enforce the policy does not seem correct. Particularly how we add HTLCs through the route. We do checks on the sending node like such.

```
fn check_outgoing_addition(&self, htlc: &Htlc) -> Result<(), ForwardingError> {
fail_forwarding_inequality!(htlc.amount_msat, >, self.policy.max_htlc_size_msat, MoreThanMaximum);
fail_forwarding_inequality!(htlc.amount_msat, <, self.policy.min_htlc_size_msat, LessThanMinimum);
fail_forwarding_inequality!(
self.in_flight.len() as u64 + 1, >, self.policy.max_htlc_count, ExceedsInFlightCount
);
fail_forwarding_inequality!(
self.in_flight_total() + htlc.amount_msat, >, self.policy.max_in_flight_msat, ExceedsInFlightTotal
);
fail_forwarding_inequality!(htlc.amount_msat, >, self.local_balance_msat, InsufficientBalance);
fail_forwarding_inequality!(htlc.cltv_expiry, >, 500000000, ExpiryInSeconds);

Ok(())
}
```

This translates to the sender checking it's own policy, not the counterparty one i.e the htlc amount should respect the counterparty policy `max_htlc_size_msat` not self. Unless there is an expectation on how the policies are specified in the simulation json file, this seems incorrect.

Start in sim_node.rs at ChannelPolicy and check_outgoing_addition, then inspect the simulation JSON that supplies each node's policy. Trace which node owns each policy during route construction and compare the checks with the counterparty's advertised restrictions. Done means the enforcement behavior and the JSON policy convention are consistent and the issue's sender-versus-counterparty concern is resolved.

Written by the indexing model from the issue text.