fix: pubdata is 0 error when using validium SL

[sidhujag]

What ❔

• Ensure a non-zero pubdata price in Validium/Custom DA mode to avoid deriving gas_per_pubdata = 0 on settlement-layer gateways.
• In core/node/fee_model/src/l1_gas_price/gas_adjuster/mod.rs, update estimate_effective_pubdata_price so that for PubdataSendingMode::Custom it returns a minimum of 800 (aligned with REQUIRED_L2_GAS_PRICE_PER_PUBDATA), preventing transaction rejections due to zero gas-per-pubdata.
• Keep Validium capping behavior consistent with Rollup in cap_pubdata_fee (no zeroing; only cap to max_blob_base_fee).

            PubdataSendingMode::Custom => {
                // For Validium/Custom DA, we need to return a minimum gas per pubdata price
                // ...
                const MIN_PUBDATA_PRICE_FOR_VALIDIUM: u64 = 800; // Same as REQUIRED_L2_GAS_PRICE_PER_PUBDATA
                MIN_PUBDATA_PRICE_FOR_VALIDIUM
            }

Reference: GitHub issue #2105 (noted in code comment).

Why ❔

• When settling on a gateway SL configured for Validium, the pubdata price previously evaluated to 0, causing the VM to derive gas_per_pubdata = 0, which is invalid and leads to “gas per pub data limit is zero” rejection.
• Setting a small, consistent minimum (800) aligns with the L1 contracts’ REQUIRED_L2_GAS_PRICE_PER_PUBDATA = 800, ensuring cross-component consistency and successful settlement.
• This change is scoped to PubdataSendingMode::Custom and does not affect Rollup/blobs/calldata paths. Base fee remains governed by fair_l2_gas_price unless pubdata cost dominates, which is unlikely at this floor.

Is this a breaking change?

• Yes
• No

Rationale: Only affects Validium/Custom DA pubdata price when it would otherwise be zero. Rollup behavior and gateway fee paths remain unchanged. No interface changes.

Operational changes

• No config or flags required.
• If operators need a different floor, they can use internal_enforced_pubdata_price in GasAdjusterConfig.
• No migration or script changes.

Checklist

• PR title corresponds to the body of PR.
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated (inline code comments explain rationale and link to issue).
• Code has been formatted via zkstack dev fmt and zkstack dev lint.