[kv] Fail multiGet on read errors instead of reporting missing keys

[zhang-arvin]

Summary

• RocksDBKv#multiGet delegates to RocksDB#multiGetAsList, which reports a key that could not be read (e.g. a block checksum mismatch on a corrupted SST) as null - the very same value it uses to signal a genuine miss. A read error was therefore silently turned into "key not found", while the single-key get() path correctly throws.
• Re-check every null result of multiGetAsList with get(), which throws on read errors. A genuine miss only pays one extra lookup and stays cheap as it is served from the bloom filter / block cache.
• Apply the same reasoning to prefixLookup() and limitScan(): an iterator stopped by an error is indistinguishable from one that reached the end of its range by isValid() alone, so the status is now checked before closing it instead of silently truncating the result set.
• Both methods now declare throws IOException, matching the same pattern as the other read paths (KvTablet.prefixLookup/limitScan already declare it, and their callers in Replica already catch IOException and wrap it into KvStorageException).

Test Plan

• Added RocksDBKvTest#testMultiGetFailsOnReadError, covering both sides of the change:
  • a missed key whose underlying read failed makes multiGet fail instead of returning null;
  • a key that genuinely does not exist is still reported as null and is not turned into an error by the added re-check.
• The failure is injected through get(), the method multiGet() uses for the re-check. Corrupting an SST on disk does not work here: RocksDB opens a database with paranoid_checks enabled by default, so the instance fails to open at all and the read path is never reached.
• Ran mvn -pl fluss-server test -Dtest=RocksDBKvTest: 13 tests, 0 failures, 0 errors.
• Ran mvn -pl fluss-server spotless:apply and spotless:check: clean.

Fixes #4484

🤖 AI-assisted changes - reviewed by human developer