Cloneable group on settings page returns stale data — direct SQL correct

Environment:

Meta Box AIO version: 3.3.4
WordPress version: 6.8.3
PHP version: 8.2.29
Bricks Builder 2.1.3
Redis object cache enabled on server
Autoloaded options: 670 options, 796 KB total

Description:
I have a Meta Box settings page with multiple cloneable groups. One specific cloneable group containing team member data with image fields returns incorrect/stale image IDs when accessed via rwmb_meta() or get_option().
The strange part: direct SQL query to wp_options returns the correct data, but WordPress's get_option() and Meta Box's rwmb_meta() return old, incorrect values.

Steps to reproduce:
- Create a settings page with a cloneable group
- Add an image field inside the cloneable group
- Add several entries with different images
- Save the settings page
- On frontend, images display incorrectly — multiple entries show the same image

Debugging findings:
1. rwmb_meta() returns wrong image IDs:

php$data = rwmb_meta('my_cloneable_group', ['object_type' => 'setting'], 'my_settings_page');
Returns image ID 2000 for entries that should have different unique IDs.

2. get_option() also returns wrong data:

php$data = get_option('my_settings_page');
$group = $data['my_cloneable_group'];
// Also shows wrong image IDs

3. Direct SQL returns CORRECT data:

phpglobal $wpdb;
$raw = $wpdb->get_var("SELECT option_value FROM {$wpdb->options} WHERE option_name = 'my_settings_page'");
$data = maybe_unserialize($raw);
// Returns correct, unique image IDs for each entry

What I tried (none fixed it):
- Flushed Redis cache on server
- Cleared WordPress transients
- Cleared all browser cache
- Re-saved the settings page multiple times
- Ran wp_cache_flush()
- Ran wp_cache_delete('my_settings_page', 'options') and wp_cache_delete('alloptions', 'options')
- Ran update_option() with fresh data from SQL — cache immediately returns old values again
- Verified only one row exists in wp_options for this option
- Disabled autoload for the option (autoload = 'no') — no change
- Site Health reports 670 autoloaded options (796 KB) — tried reducing but issue persists

Important: Other cloneable groups on the same settings page work correctly. Only this specific group has the issue.

Workaround:
The only permanent fix was adding a filter to bypass the cache entirely:

phpadd_filter('pre_option_my_settings_page', function($pre_option) {
    static $cached = null;
    
    if ($cached !== null) {
        return $cached;
    }
    
    global $wpdb;
    $raw = $wpdb->get_var("SELECT option_value FROM {$wpdb->options} WHERE option_name = 'my_settings_page'");
    $cached = maybe_unserialize($raw);
    
    return $cached;
});

This reads directly from the database, caches per request, and guarantees correct data.

Conclusion:
Something in Meta Box's storage or retrieval layer for settings pages is caching incorrect data that persists even after:
- Object cache flush
- Transient flush
- Redis flush
- Disabling autoload
- Re-saving the option

The database contains correct values, but they're never served to the application through normal WordPress/Meta Box functions.
This appears to be a bug in how Meta Box handles cloneable groups on settings pages, possibly related to how option values are serialized/unserialized or cached internally.
Has anyone else experienced this? Any insights from the Meta Box team?