Add Solana as source chain, extend readme

[0xBreadguy]

• Add Solana as source chain for bridged assets

• Add Solana to CHAINS config with chainId 101 (per Uniswap token-lists standard)
• Added evmCompatible flag to distinguish EVM vs non-EVM chains
• Introduced EvmChain and SourceChain types for clarity
• CHAIN_IDS excludes Solana (source tracking only, not tokenlist output)
• Update README with documentation and example

This enables orderly tracking of tokens bridged from Solana (e.g., WSOL via Wormhole) while maintaining the EVM-focused tokenlist output.

• Add source chain info to token extensions

When a token is bridged from a non-EVM chain (e.g., Solana), the generated tokenlist now includes source chain info in the extensions:

• sourceChain: Human-readable chain name (e.g., 'Solana')
• sourceChainId: Chain ID per Uniswap standard (e.g., 101)
• sourceAddress: Original token address on source chain

Example output for WSOL:
{
"extensions": {
"sourceChain": "Solana",
"sourceChainId": 101,
"sourceAddress": "So11111111111111111111111111111111111111112"
}
}

Changes:

• chains.ts: Added SOURCE_CHAIN_IDS export
• types.ts: Added sourceChain/sourceChainId/sourceAddress to TokenExtensions
• generate.ts: Detect source chains and populate extensions
• README.md: Updated documentation with example output

• Use string identifier for non-EVM source chains

Instead of numeric chainId (which is EVM-specific), use simple lowercase string identifiers for non-EVM source chains:

• sourceChain: "solana" (not 101)
• sourceAddress: native format address

This avoids confusion about 'what number is Solana?' and is more readable.

Changes:

• Removed sourceChainId from TokenExtensions
• Removed SOURCE_CHAIN_IDS, replaced with SOURCE_CHAINS array
• Updated generator to use chain key directly as identifier
• Updated README examples

• Improve README with comprehensive documentation

• Added clear table of contents with horizontal rules
• Documented all data.json fields with tables
• Added examples for each token type:
  • Native tokens
  • Bridged from Ethereum
  • Bridged from Solana (non-EVM)
• Created Extensions Reference section explaining each field
• Added extension examples for common scenarios
• Improved formatting and readability
• Added full output example

• Add comprehensive bridge mechanics tracking

New schema for tracking token origins and bridge mechanisms:

data.json per-chain fields:

• isOrigin: boolean - whether token originated on this chain
• mechanism: 'native' | 'lock' | 'mint' | 'burn'
• lockbox: address where tokens are locked (for lock mechanism)
• bridge: bridge/OFT endpoint address

Generated output extensions:

• isOrigin: origin chain indicator
• originChain: which chain has canonical supply
• mechanism: how tokens move on this chain
• lockboxAddress: where backing tokens are locked
• bridgeAddress: mint/burn contract
• bridgeType: 'canonical' or 'others'

This enables data trackers to:

1. Identify origin chains to avoid double-counting
2. Track locked tokens that back minted supply
3. Understand burn vs lock mechanics

README updates:

• Complete schema documentation with tables
• 5 detailed examples covering all scenarios:
  • Native token (single chain)
  • Canonical bridge (ETH)
  • OFT with lockbox (CUSD)
  • Pure OFT burn & mint
  • Bridged from Solana
• Extensions reference
• Data tracker guidance section

• Simplify: remove lockbox, use bridge + mechanism

Cleaner schema:

• bridge field meaning depends on mechanism:
  • mechanism: 'lock' → bridge = lockbox address
  • mechanism: 'mint/burn' → bridge = endpoint address
• Removed redundant lockbox field
• Added originBridgeAddress + originMechanism for non-origin chains

This lets data trackers see:

• Where tokens are locked (originBridgeAddress when originMechanism=lock)
• What bridge to watch on each chain

Updated README with cleaner examples and extension reference.

[SilasZhr]

LGTM.
Mind running the formatter before merging?

[0xBreadguy]

I had crumb run prettier for us @SilasZhr - please confirm and we can move forward