feat: carry real non-EVM CCIP addresses in a ccipNative{} plane

[aelmanaa]

This pull request introduces and documents support for non-EVM (non-Ethereum Virtual Machine) chain address formats in the project configuration system. The most significant changes are the addition of the ccipNative{} block and nativeChainId field for non-EVM chains (such as Solana and Aptos), ensuring that native chain addresses and IDs are stored in a format appropriate to each chain family. The documentation and sync scripts have been updated to reflect and enforce this separation, preventing non-EVM addresses from being incorrectly placed in the EVM-specific ccip{} block, which would break tooling for all chains.

Key changes:

1. Non-EVM Chain Support in Configuration

• Added ccipNative{} and nativeChainId fields to non-EVM chain config files (e.g., solana-devnet.json, aptos-testnet.json) to store native-format addresses and real chain IDs, while keeping ccip{} as an all-zero EVM skeleton and chainId as "0" for compatibility. [1] [2] [3] [4]

2. Documentation Updates

• Updated docs/config-architecture.md and docs/config-schema.md to explain the new ccipNative{} and nativeChainId fields, their purpose, and their usage in non-EVM chains, including the rationale for keeping EVM and non-EVM fields separate. [1] [2] [3] [4] [5]
• Added explicit warnings and troubleshooting guidance in docs/gotchas/index.md and docs/troubleshooting/index.md about the consequences of putting non-EVM addresses in ccip{} and how to diagnose and fix related issues. [1] [2]

3. Sync Script Enhancements

• Modified SyncCcipConfig.s.sol to fetch and write ccipNative{} and nativeChainId for non-EVM chains during sync operations, ensuring these fields are API-owned and correctly maintained. [1] [2] [3]

These changes ensure robust separation between EVM and non-EVM chain configuration data, preventing cross-family incompatibilities and improving the reliability of configuration tooling.