CASSANDRA-20570: Fixed Leveled Compaction doesn't validate maxBytesForLevel when the table is altered/created

[nikhilkumawat03]

Issue Description:

Fuzz testing revealed a RuntimeException in LeveledManifest.maxBytesForLevel during repair operations when compaction parameters cause the calculated maximum bytes for a level to exceed Long.MAX_VALUE (9,223,372,036,854,775,807). The error occurs with inputs like fanout_size=90, sstable_size_in_mb=1088, and level=8, resulting in Math.pow(90, 8) * 1141899264 ≈ 4.9155 × 10²⁴, which exceeds Long.MAX_VALUE. The issue arises because LeveledCompactionStrategy does not validate these parameters during table creation, allowing invalid configurations to persist until repair.

The original error (from LeveledManifest.java):

java.lang.RuntimeException: At most 9223372036854775807 bytes may be in a compaction level; your maxSSTableSize must be absurdly high to compute 4.915501902751334E24

This PR adds proactive validation in LeveledCompactionStrategy.validateOptions to ensure fanout_size and sstable_size_in_mb do not cause an overflow, throwing a ConfigurationException during CREATE TABLE or ALTER TABLE instead of failing later during repair.

Example which created issue during fuzz testing (CASSANDRA-20570)

CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
CREATE TABLE test.table1 (k int PRIMARY KEY, v int)
    WITH compaction = {
        'class': 'LeveledCompactionStrategy',
        'fanout_size': '90',
        'sstable_size_in_mb': '1088'
    };

Patch by: Nikhil Kumawat;
Reviewed by: TBD
JIRA: CASSANDRA-20570

[dcapwell]

mostly small changes but direction i am +1 on. Will give my official +1 once open comments are addressed