Enable ISeq caching to improve performance

[dwelch-r7]

---

Description

Enable bootsnap's ISeq compile cache (compile_cache_iseq: true) to improve msfconsole startup time.

Bootsnap already caches $LOAD_PATH lookups (added in #17809), but the ISeq compile cache was left disabled. The ISeq cache compiles Ruby source files to bytecode on first load and serves the pre-compiled bytecode on subsequent boots, avoiding repeated parsing and compilation of ~500+ Ruby files during startup.

This was originally disabled with the comment "breaks coverage reporting" — but we don't do this in CI anymore, if we want to do it in the future it makes more sense to figure out how we should deal with this issue then rather than guess at the best way now when we aren't doing coverage

Verification Steps

1. • Delete the existing bootsnap cache: rm -rf ~/.msf4/bootsnap_cache
2. • Start msfconsole — first boot builds the cache (may be slightly slower)
3. • Exit and start msfconsole again — second boot should be noticeably faster
4. • Run hyperfine --warmup 3 "bundle exec ruby ./msfconsole -q -x 'exit'" should be improved from master

Test Evidence

# Before (compile_cache_iseq: false)
Benchmark 1: bundle exec ruby ./msfconsole -q -x 'exit'
  Time (mean ± σ):      4.242 s ±  0.066 s    [User: 3.024 s, System: 1.281 s]
  Range (min … max):    4.135 s …  4.366 s    10 runs

# After (compile_cache_iseq: true)
Benchmark 1: bundle exec ruby ./msfconsole -q -x 'exit'
  Time (mean ± σ):      3.941 s ±  0.069 s    [User: 2.358 s, System: 1.404 s]
  Range (min … max):    3.849 s …  4.083 s    10 runs

Environment

Field	Details
Operating System	macOS (26.5.2)
Target Software/Hardware	Metasploit Framework (Ruby 3.3.8)

AI Usage Disclosure

Kiro

Pre-Submission Checklist

• No sensitive information (IP addresses, credentials, API keys, hashes) in code or documentation
• Tested on the target environment specified in the Environment section above
• Read the CONTRIBUTING.md and module acceptance guidelines

[adfoster-r7]

I think it'd be worth a cycle just double checking what the bootsnap dir looks like after these changes, and if there'll be any issues for pro/console users. I think it should auto-update transparently, but it'd be worth sanity checking things here 👀

Also worth double checking that the folder won't indefinitely grow over time after changes are made in each release etc, as we don't have any logic to clean this up

[dwelch-r7]

I think it'd be worth a cycle just double checking what the bootsnap dir looks like after these changes, and if there'll be any issues for pro/console users. I think it should auto-update transparently, but it'd be worth sanity checking things here 👀

Also worth double checking that the folder won't indefinitely grow over time after changes are made in each release etc, as we don't have any logic to clean this up

Is this what you were expecting?

$ ls -lah ~/.msf4/bootsnap_cache                                                                                                                                         ‹ruby-3.3.8@metasploit-framework›
total 8
drwxr-xr-x   4 dwelch  staff   128B  3 Jul 15:23 .
drwxr-xr-x  25 dwelch  staff   800B  3 Jul 15:23 ..
drwxr-xr-x   3 dwelch  staff    96B  3 Jul 15:43 bootsnap
-rw-r--r--   1 dwelch  staff   275B  3 Jul 15:46 metadata.yaml

~/dev/metasploit-framework on  upstream-master! ⌚ 15:47:20
$ ls -lah ~/.msf4/bootsnap_cache/bootsnap                                                                                                                                ‹ruby-3.3.8@metasploit-framework›
total 1200
drwxr-xr-x  3 dwelch  staff    96B  3 Jul 15:43 .
drwxr-xr-x  4 dwelch  staff   128B  3 Jul 15:23 ..
-rw-r--r--  1 dwelch  staff   598K  3 Jul 15:43 load-path-cache

[adfoster-r7]

Let's do a Pro QA run, and an omnibus build run, to verify that we're not shipping this cache folder