SuperchainERC20: Prevent Initial Supply Duplication Across Networks

## **Is your feature request related to a problem? Please describe.**
The **SuperchainERC20** contract currently deploys with the same `initialSupply` across all Superchain networks. This leads to **unexpected supply inflation**, where if a user sets `initialSupply = 1,000,000` on one network, the total supply across all networks becomes `network_count * 1,000,000`.

This is problematic because:
- It **breaks the expected behavior** of cross-chain tokens, where minting and burning should ensure a unified total supply across all networks.
- The **supply is not controlled**, causing economic inconsistencies in tokenomics.
- The expected behavior is that a token should start with supply **only on the native chain** and have a `0` supply on all other chains until bridged.

## **Describe the solution you'd like**
To prevent unintended inflation, I propose modifying the **SuperchainERC20** constructor to include a `nativeChainId` parameter.

### **Solution**
1. **Introduce a `nativeChainId` parameter** in the constructor.
2. **Only mint `initialSupply` on the native chain**.
3. **Other chains start with `0` supply**, and minting occurs only through bridging.

### **Code Example:**
```solidity
constructor(
string memory name,
string memory symbol,
uint256 initialSupply,
uint256 nativeChainId
) ERC20(name, symbol) {
if (block.chainid == nativeChainId) {
_mint(msg.sender, initialSupply);
}
}
```

- This ensures that `initialSupply` is **only created once** on the native chain.
- On all other networks, the **initial supply is 0**, and cross-chain bridge transactions will mint new tokens as needed.

## **Describe alternatives you've considered**
1. **Manually burning tokens on extra networks**
- This is inefficient and requires constant monitoring.
- Users may forget or fail to burn tokens, leading to supply inconsistencies.

2. **Using a global registry to track deployments**
- More complex and introduces additional overhead.
- Would require an external contract or centralized tracking system.

3. **Enforcing mint/burn strictly via bridge mechanisms**
- The best long-term solution, but it requires deeper integration with Superchain bridge logic.

## **Additional Context**
- This issue affects **all Superchain networks**, leading to **unexpected inflation** of deployed tokens.
- Implementing this fix ensures that **total supply remains predictable and controlled**.
- This change aligns **SuperchainERC20** with proper **cross-chain asset management best practices**.

Would love to hear feedback and thoughts from the team on this proposal!

Start by locating the SuperchainERC20 contract and its constructor and review how initial supply is handled across network deployments. Then inspect the existing bridge minting and burning behavior and related tests, if present. Done means the supply is created only on the native chain without breaking cross-chain token operations, with coverage for native and non-native deployments.

Written by the indexing model from the issue text.