cache_drop_all seg fault

While trying to isolate my seg fault from https://github.com/libvips/ruby-vips/issues/429, I found another seg fault which is easy to reproduce:

require 'vips' 
path = "/Users/curi/w/test/test.png"
# vi1 = Vips::Image.new_from_file(path) # loads fine. irrelevant to crash
Vips.cache_drop_all # causes seg fault on next image load
vi2 = Vips::Image.new_from_file(path) # seg fault

macOS Tahoe 26.1, M1 chip, ruby 3.4.7, ruby-vips 2.3.0, vips 8.16.1 via homebrew.

irb(main):001> require 'vips' 
irb(main):002> path = "/Users/curi/w/test/test.png"
irb(main):003> vi1 = Vips::Image.new_from_file(path) # removing this doesn't change the result
irb(main):004> Vips.cache_drop_all # causes seg fault on next image load
irb(main):005> vi2 = Vips::Image.new_from_file(path) # seg fault

(process:41415): GLib-CRITICAL **: 13:19:13.336: g_hash_table_lookup: assertion 'hash_table != NULL' failed

(process:41415): GLib-CRITICAL **: 13:19:13.336: g_hash_table_lookup: assertion 'hash_table != NULL' failed

(process:41415): GLib-CRITICAL **: 13:19:13.336: g_hash_table_insert_internal: assertion 'hash_table != NULL' failed

(process:41415): GLib-CRITICAL **: 13:19:13.336: g_hash_table_lookup: assertion 'hash_table != NULL' failed
/Users/curi/.gem/ruby/3.4.7/gems/ruby-vips-2.3.0/lib/vips/operation.rb:225: [BUG] Segmentation fault at 0x0000000000000018
ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [arm64-darwin25]

-- Crash Report log information --------------------------------------------
   See Crash Report log file in one of the following locations:             
     * ~/Library/Logs/DiagnosticReports                                     
     * /Library/Logs/DiagnosticReports                                      
   for more details.                                                        
Don't forget to include the above Crash Report log file in bug reports.     

-- Control frame information -----------------------------------------------
c:0025 p:---- s:0160 e:000159 CFUNC  :vips_cache_operation_build
c:0024 p:0005 s:0155 e:000154 METHOD /Users/curi/.gem/ruby/3.4.7/gems/ruby-vips-2.3.0/lib/vips/operation.rb:225
c:0023 p:0277 s:0150 E:000690 METHOD /Users/curi/.gem/ruby/3.4.7/gems/ruby-vips-2.3.0/lib/vips/operation.rb:481
c:0022 p:0072 s:0128 e:000127 METHOD /Users/curi/.gem/ruby/3.4.7/gems/ruby-vips-2.3.0/lib/vips/image.rb:288
c:0021 p:0029 s:0119 E:0018e8 EVAL   (irb):5 [FINISH]
c:0020 p:---- s:0113 e:000112 CFUNC  :eval
c:0019 p:0020 s:0105 e:000104 METHOD /Users/curi/.gem/ruby/3.4.7/gems/irb-1.15.3/lib/irb/workspace.rb:101
c:0018 p:0090 s:0098 e:000097 METHOD /Users/curi/.gem/ruby/3.4.7/gems/irb-1.15.3/lib/irb/context.rb:591
c:0017 p:0057 s:0090 e:000089 METHOD /Users/curi/.gem/ruby/3.4.7/gems/irb-1.15.3/lib/irb/context.rb:557

Start with the reproducible IRB sequence in the issue, especially Vips.cache_drop_all followed by Vips::Image.new_from_file. Inspect lib/vips/operation.rb around line 225 and lib/vips/image.rb around line 288, then compare the GLib warnings with the crash stack. Done means the sequence no longer segfaults and the reported cache state is handled safely.